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

Re: [Pharo-users] How to generically find methods in class hierarchies? (Aka narrow spotter?)

by Ben Coman

On Sat, 30 Mar 2019 at 07:46, Tim Mackinnon <tim(a)testit.works> wrote: > Iâm wondering if there are better ways of finding things that I am missing. > > In another thread I was asking about how to wrap the lookup of an item at > an index in a collection. > > I had browsed the collection hierarchy and not seen anything (I kept > coming back to the fact that I dont find the protocol categories very > helpful, particularly in the collection hierarchy). > > I had also used spotter - and to explain - if you type âwrapâ into > spotter there are 400 methods that come up, and when you scroll down them, > after about 100 the list starts to go blank (bug?). > > Spotter seems like the key however, but Iâm wondering if there is a way to > search for âwrapâ methods in a hierarchy (limit it, and not search the full > image)? I tried typing Collection, diving in and typing wrap - but that > doesnât work. However I thought I had read that there was a way to search > in a hierarchy - but I can seem to work it out? > > (Also - while the show inherited methods in Calypso is useful - I find > itâs not great when you have half a concept in mind as depending on > prefixes and some of the less common naming of things, it can be hard to > find stuff when itâs alphabetical and not filtered. > > So is there a trick Iâm missing? > I mentioned in another thread before seeing this post. Try... Tools > Finder > Examples > #(10 20 30 40) . 5 . 10 P.S. It would be good in Exercism to talk students through using this tool. cheers -ben

March 30, 2019

Re: [Pharo-users] Easiest way to wrap around the indexed value in a list (mod doesn't quite work)

by Ben Coman

On Sat, 30 Mar 2019 at 01:09, Peter Kenny <peter(a)pbkresearch.co.uk> wrote: > Tim > > Going back to your original question, the answer is there all the time but > buried in the enormous method dictionaries of the Collection subclasses. And we have Tools > Finder > Examples > #(10 20 30 40) . 5 . 10 to help unbury such methods... > If > you look at SequenceableCollection>>atWrap: you will see that it does > exactly what you want. > > To get the item before the first, i.e. the zeroth: > #(1 2 3 4) atWrap: 0 => 4 > > To get the item after the last: > #(1 2 3 4) atWrap: 5 => 1 > > As seen here, the method is inherited by Array, so it should do all you > want. > > HTH > > Peter > > --------------- > > Marcus Denker-4 wrote > >> On 29 Mar 2019, at 14:24, Ben Coman < > >> I believe there have been some proposals to separate out the Process > >> related LinkedList stuff, but I can't remember the exact arguments. > > > > Yes, we did thatâ¦ there is now ProcessList. > > > > We ran into that problem far too often âhey, LinkedList can be cleaned up > > easily like this!â â> boom, everything broken. > > > > Now we have ProcessList where it matters if code is changed to introduce > a > > message send more and LinkedList where it does not. > Cool !! cheers -ben

March 30, 2019

How to generically find methods in class hierarchies? (Aka narrow spotter?)

by Tim Mackinnon

Iâm wondering if there are better ways of finding things that I am missing. In another thread I was asking about how to wrap the lookup of an item at an index in a collection. I had browsed the collection hierarchy and not seen anything (I kept coming back to the fact that I dont find the protocol categories very helpful, particularly in the collection hierarchy). I had also used spotter - and to explain - if you type âwrapâ into spotter there are 400 methods that come up, and when you scroll down them, after about 100 the list starts to go blank (bug?). Spotter seems like the key however, but Iâm wondering if there is a way to search for âwrapâ methods in a hierarchy (limit it, and not search the full image)? I tried typing Collection, diving in and typing wrap - but that doesnât work. However I thought I had read that there was a way to search in a hierarchy - but I can seem to work it out? (Also - while the show inherited methods in Calypso is useful - I find itâs not great when you have half a concept in mind as depending on prefixes and some of the less common naming of things, it can be hard to find stuff when itâs alphabetical and not filtered. So is there a trick Iâm missing? Tim Ps - Peter spotter the method I was after was called atWrap:, so it doesnât begging with w, and hence I missed it. Sent from my iPhone

March 29, 2019

Re: [Pharo-users] Easiest way to wrap around the indexed value in a list (mod doesn't quite work)

by Peter Kenny

We could probably mine this forever to get interesting connections, but I shall restrict myself to three (and then shut up). a. The code for SequenceableCollection>>atWrap: is a single line, which exactly reproduces Tim's original method. Maybe a hint for programming strategy - if code is mysterious, encapsulate it in a method with an informative name. b. Modulo reduction to achieve wrapping just works with zero-based indexing. The -1 and +1 can be seen as temporarily converting to zero-based indexing and then converting back. c. If you think of backward shifting more than one place, you end up with a negative index. This works equally well (I checked!), but it is not obvious that it must, because it is not obvious that <negativeInteger> \\ <positiveInteger> has to be positive - I have encountered systems with a different convention. HTH Peter Kenny Tim Mackinnon wrote > Peter - nice spot. Iâm glad we kept this thread running as I keep learning > more of the nooks and crannies. > > I keep finding that between odd naming (although in this case Iâm shocked > I missed that one - I need to get better at using spotter) and unfortunate > method categorisation, that I struggle to find these gems. > > If I searched for âwrapâ, can I do it over a hierarchy? I need to try > that, as this would eliminate prefix ordering. > > > > Tim > > Sent from my iPhone > >> On 29 Mar 2019, at 17:28, Sven Van Caekenberghe < > sven@ > > wrote: >> >> Haha, great discussion, great find. Amazing that all these things are >> just already there. >> >> Pharo/Smalltalk programming is really 'studying the problem and the >> existing system, moving it to the desired state with as little work as >> possible' - including the use of frameworks and libraries. >> >>> On 29 Mar 2019, at 18:08, Peter Kenny < > peter@.co > > wrote: >>> >>> Tim >>> >>> Going back to your original question, the answer is there all the time >>> but >>> buried in the enormous method dictionaries of the Collection subclasses. >>> If >>> you look at SequenceableCollection>>atWrap: you will see that it does >>> exactly what you want. >>> >>> To get the item before the first, i.e. the zeroth: >>> #(1 2 3 4) atWrap: 0 => 4 >>> >>> To get the item after the last: >>> #(1 2 3 4) atWrap: 5 => 1 >>> >>> As seen here, the method is inherited by Array, so it should do all you >>> want. >>> >>> HTH >>> >>> Peter >>> > >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 29, 2019

Re: [Pharo-users] Easiest way to wrap around the indexed value in a list (mod doesn't quite work)

by Tim Mackinnon

Peter - nice spot. Iâm glad we kept this thread running as I keep learning more of the nooks and crannies. I keep finding that between odd naming (although in this case Iâm shocked I missed that one - I need to get better at using spotter) and unfortunate method categorisation, that I struggle to find these gems. If I searched for âwrapâ, can I do it over a hierarchy? I need to try that, as this would eliminate prefix ordering. Tim Sent from my iPhone > On 29 Mar 2019, at 17:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Haha, great discussion, great find. Amazing that all these things are just already there. > > Pharo/Smalltalk programming is really 'studying the problem and the existing system, moving it to the desired state with as little work as possible' - including the use of frameworks and libraries. > >> On 29 Mar 2019, at 18:08, Peter Kenny <peter(a)pbkresearch.co.uk> wrote: >> >> Tim >> >> Going back to your original question, the answer is there all the time but >> buried in the enormous method dictionaries of the Collection subclasses. If >> you look at SequenceableCollection>>atWrap: you will see that it does >> exactly what you want. >> >> To get the item before the first, i.e. the zeroth: >> #(1 2 3 4) atWrap: 0 => 4 >> >> To get the item after the last: >> #(1 2 3 4) atWrap: 5 => 1 >> >> As seen here, the method is inherited by Array, so it should do all you >> want. >> >> HTH >> >> Peter >> >> >> Marcus Denker-4 wrote >>>> On 29 Mar 2019, at 14:24, Ben Coman < >> >>> btc@ >> >>> > wrote: >>>> >>>> >>>> >>>> On Fri, 29 Mar 2019 at 18:57, Tim Mackinnon < >> >>> tim@ >> >>> > wrote: >>>> Hi Peter - yes of course you are right that its malleable, I guess Iâm >>>> often suprised about the things we leave out and then discover weird >>>> things weâve put in. >>>> >>>> I had a quick look at LinkedList (I should have thought of that) - I >>>> might be able to do something with that (and this is now more out of >>>> curiosity) - but gosh its an easy way to crash your image. Having linked >>>> the first to the last, and then tried a quick: list after: $n - Iâm now >>>> guessing Iâm stuck in an infinite loop that even Cmd . wonât break out >>>> of!!!! ouch. >>>> >>>> If you look at Hier(archy) of LinkList you'll see Semaphore underneath >>>> it. >>>> I'm not sure, but there may be some VM magic around Semaphore and Process >>>> management that makes it fragile to changes. >>>> I believe there have been some proposals to separate out the Process >>>> related LinkedList stuff, but I can't remember the exact arguments. >>> >>> Yes, we did thatâ¦ there is now ProcessList. >>> >>> We ran into that problem far too often âhey, LinkedList can be cleaned up >>> easily like this!â â> boom, everything broken. >>> >>> Now we have ProcessList where it matters if code is changed to introduce a >>> message send more and LinkedList where it does not. >>> >>> Marcus >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

March 29, 2019

Re: [Pharo-users] Easiest way to wrap around the indexed value in a list (mod doesn't quite work)

by Sven Van Caekenberghe

Haha, great discussion, great find. Amazing that all these things are just already there. Pharo/Smalltalk programming is really 'studying the problem and the existing system, moving it to the desired state with as little work as possible' - including the use of frameworks and libraries. > On 29 Mar 2019, at 18:08, Peter Kenny <peter(a)pbkresearch.co.uk> wrote: > > Tim > > Going back to your original question, the answer is there all the time but > buried in the enormous method dictionaries of the Collection subclasses. If > you look at SequenceableCollection>>atWrap: you will see that it does > exactly what you want. > > To get the item before the first, i.e. the zeroth: > #(1 2 3 4) atWrap: 0 => 4 > > To get the item after the last: > #(1 2 3 4) atWrap: 5 => 1 > > As seen here, the method is inherited by Array, so it should do all you > want. > > HTH > > Peter > > > Marcus Denker-4 wrote >>> On 29 Mar 2019, at 14:24, Ben Coman < > >> btc@ > >> > wrote: >>> >>> >>> >>> On Fri, 29 Mar 2019 at 18:57, Tim Mackinnon < > >> tim@ > >> > wrote: >>> Hi Peter - yes of course you are right that its malleable, I guess Iâm >>> often suprised about the things we leave out and then discover weird >>> things weâve put in. >>> >>> I had a quick look at LinkedList (I should have thought of that) - I >>> might be able to do something with that (and this is now more out of >>> curiosity) - but gosh its an easy way to crash your image. Having linked >>> the first to the last, and then tried a quick: list after: $n - Iâm now >>> guessing Iâm stuck in an infinite loop that even Cmd . wonât break out >>> of!!!! ouch. >>> >>> If you look at Hier(archy) of LinkList you'll see Semaphore underneath >>> it. >>> I'm not sure, but there may be some VM magic around Semaphore and Process >>> management that makes it fragile to changes. >>> I believe there have been some proposals to separate out the Process >>> related LinkedList stuff, but I can't remember the exact arguments. >> >> Yes, we did thatâ¦ there is now ProcessList. >> >> We ran into that problem far too often âhey, LinkedList can be cleaned up >> easily like this!â â> boom, everything broken. >> >> Now we have ProcessList where it matters if code is changed to introduce a >> message send more and LinkedList where it does not. >> >> Marcus > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 29, 2019

Re: [Pharo-users] Easiest way to wrap around the indexed value in a list (mod doesn't quite work)

by Peter Kenny

Tim Going back to your original question, the answer is there all the time but buried in the enormous method dictionaries of the Collection subclasses. If you look at SequenceableCollection>>atWrap: you will see that it does exactly what you want. To get the item before the first, i.e. the zeroth: #(1 2 3 4) atWrap: 0 => 4 To get the item after the last: #(1 2 3 4) atWrap: 5 => 1 As seen here, the method is inherited by Array, so it should do all you want. HTH Peter Marcus Denker-4 wrote >> On 29 Mar 2019, at 14:24, Ben Coman < > btc@ > > wrote: >> >> >> >> On Fri, 29 Mar 2019 at 18:57, Tim Mackinnon < > tim@ > > wrote: >> Hi Peter - yes of course you are right that its malleable, I guess Iâm >> often suprised about the things we leave out and then discover weird >> things weâve put in. >> >> I had a quick look at LinkedList (I should have thought of that) - I >> might be able to do something with that (and this is now more out of >> curiosity) - but gosh its an easy way to crash your image. Having linked >> the first to the last, and then tried a quick: list after: $n - Iâm now >> guessing Iâm stuck in an infinite loop that even Cmd . wonât break out >> of!!!! ouch. >> >> If you look at Hier(archy) of LinkList you'll see Semaphore underneath >> it. >> I'm not sure, but there may be some VM magic around Semaphore and Process >> management that makes it fragile to changes. >> I believe there have been some proposals to separate out the Process >> related LinkedList stuff, but I can't remember the exact arguments. > > Yes, we did thatâ¦ there is now ProcessList. > > We ran into that problem far too often âhey, LinkedList can be cleaned up > easily like this!â â> boom, everything broken. > > Now we have ProcessList where it matters if code is changed to introduce a > message send more and LinkedList where it does not. > > Marcus -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 29, 2019

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

by Holger Freyther

> On 29. Mar 2019, at 10:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Holger, Sven, All! Thanks for moving it to GitHub! Pharo Days: I am in APAC right now and I am not sure if I make it. I am hesitating. Maybe we can have a Google Hangout to discuss this (if not too inconvenient for the ones present?). Unix system resolver config discovery: The FreeBSD manpages are quite good. I think we need to parse resolv.conf, hosts and nsswitch (Linux, FreeBSD). It's probably okay to not support everything initially (e.g. I have never seen sortlist being used in my unix career). Also the timeouts for re-reading these file are interesting (inotify/stat/lazily reread might be preferable). https://www.freebsd.org/cgi/man.cgi?resolv.conf https://www.freebsd.org/cgi/man.cgi?hosts https://www.freebsd.org/cgi/man.cgi?query=nsswitch.conf Windows resolver config discovery: It seems https://docs.microsoft.com/en-us/windows/desktop/api/iphlpapi/nf-iphlpapi-g… populates a FIXED_INFO that includes a list of resolver addresses. MacOS config discovery: Starting with the Unix implementation might not be terrible. My interest: I would like Pharo to improve on the networking side and I have worked with recursive resolvers and authoritative servers in my last job. It seemed obvious to combine these two when Norbert tried NetNameResolver and only got one IPv4 address and I looked at the C implementation. The other interest is that I am following the IETF DNS development (on dnsop/dprive/doh with interesting topics). I think having a manageable DNS toolkit will help me to play with specs/standards in the future. More responses inline. >> 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? > > For years there is this issue in Pharo that if we build features that require internet access (say for example automatic loading of the Catalog when you start using Spotter, but there are many more places where this could add lots of value), that people say "don't do this, because it won't work when I have slow or no internet (like on a train)". This sounds like "bearer management"? It seems like consulting the OS for the network status might be better/more consistent? > The core cause of the problems is that the current NameResolver is totally blocking, especially in failure cases, which gives a terrible experience. Yes. That's horrible. The MacOS implementation is actually asynchronous but has a level of concurrency of one. :( > One way to fix this would be with the concept of NetworkState, a cheap, reliable, totally non-blocking way to test if the image has a working internet connection. Related is the option of 'Airplane Mode', so that you can manually say: "consider the internet unreachable". Makes sense but is difficult as well. Just because we can't resolve one name doesn't mean that NetNameResolver won't lock-up soon after. :( I think we have to come up with ways to deal with just because all I/O is blocking in a Pharo Process doesn't mean that there is no concurrency. Is this only true for files+dns? In the bigger context I would like to have something like CSP in Pharo. > I would *very* much prefer not to depend on any obscure, hard to maintain VM code (FFI would just be acceptable). ack. > What I tried/implemented in NeoDNSClient (which inherits from the one-shot NeoSimplifiedDNSClient) is a requestQueue and a cache (respecting ttl), where clients put a request on the requestQueue and wait on a semaphore inside the request (respecting their call's timeout). A single process (that starts/stops as needed) handles the sending & receiving of the actual protocol, signalling the matching request's semaphore. (The #beThreadSafe option needs a bit more work though). In my implementation I have separated the transports in their own classes. For UDP we always want to have a fresh socket to get a new source port assigned, for TCP, TLS and DoH it might make sense to keep the connection open a bit. In some ways if I open 15 db connections with Voyage, I'm not concerned about 15 DNS queries. The implementation will be a lot more simple (no synchronization, no need to reason about concurrency) but on the other hand coordination is what we have today. I think we can achieve coordination with an easier way. E.g. register pending requests and allow other clients to subscribe on the result. > I am curious though, what was your initial motivation for starting PaleoDNS ? Which concrete issues did you encounter that you wanted to fix ? What I like and found with my implementation: * It would be nice if ZdcAbstractSocketStream understood uintX/uintX: * My record classes can be parsed and serialized. In generalI want to be "sender" and "receiver". * Separating the transport by class might make sense like my implementation. I have TCP, UDP and TLS. * My decompression is subject to infinite loops but I think the other code too? * We should aim to enable EDNS(0) support by default. * We should have 0x20 randomization, random transaction ids, and comparing query and result in a final stub resolver. * timeout and RTT handling should be adaptive. Chromium's stub resolver might have a good example. * We should have a minimal implementation in the image and be extendable. have a great weekend! holger

March 29, 2019

Re: [Pharo-users] Easiest way to wrap around the indexed value in a list (mod doesn't quite work)

by Marcus Denker

> On 29 Mar 2019, at 14:24, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Fri, 29 Mar 2019 at 18:57, Tim Mackinnon <tim(a)testit.works> wrote: > Hi Peter - yes of course you are right that its malleable, I guess Iâm often suprised about the things we leave out and then discover weird things weâve put in. > > I had a quick look at LinkedList (I should have thought of that) - I might be able to do something with that (and this is now more out of curiosity) - but gosh its an easy way to crash your image. Having linked the first to the last, and then tried a quick: list after: $n - Iâm now guessing Iâm stuck in an infinite loop that even Cmd . wonât break out of!!!! ouch. > > If you look at Hier(archy) of LinkList you'll see Semaphore underneath it. > I'm not sure, but there may be some VM magic around Semaphore and Process management that makes it fragile to changes. > I believe there have been some proposals to separate out the Process related LinkedList stuff, but I can't remember the exact arguments. Yes, we did thatâ¦ there is now ProcessList. We ran into that problem far too often âhey, LinkedList can be cleaned up easily like this!â â> boom, everything broken. Now we have ProcessList where it matters if code is changed to introduce a message send more and LinkedList where it does not. Marcus

March 29, 2019

Re: [Pharo-users] Easiest way to wrap around the indexed value in a list (mod doesn't quite work)

by Ben Coman

On Fri, 29 Mar 2019 at 18:57, Tim Mackinnon <tim(a)testit.works> wrote: > Hi Peter - yes of course you are right that its malleable, I guess Iâm > often suprised about the things we leave out and then discover weird things > weâve put in. > > I had a quick look at LinkedList (I should have thought of that) - I might > be able to do something with that (and this is now more out of curiosity) - > but gosh its an easy way to crash your image. Having linked the first to > the last, and then tried a quick: list after: $n - Iâm now guessing Iâm > stuck in an infinite loop that even Cmd . wonât break out of!!!! ouch. > If you look at Hier(archy) of LinkList you'll see Semaphore underneath it. I'm not sure, but there may be some VM magic around Semaphore and Process management that makes it fragile to changes. I believe there have been some proposals to separate out the Process related LinkedList stuff, but I can't remember the exact arguments. cheers -ben > > Tim > > On 29 Mar 2019, at 10:20, Peter Kenny <peter(a)pbkresearch.co.uk> wrote: > > Tim > > But the beauty of Smalltalk is that, if you need to use a particular > structure frequently, you can make it an object just by subclassing > something useful. In this case, you could create CircularList by > subclassing > SequenceableCollection and re-implementing #before and #after (and maybe > tidying up #add if you don't want the circle to be extendable). > > Pursuing this line of thought, we already have one specialized subclass in > LinkedList. If the last element is linked to the first, this becomes > circular. I glanced at some of the methods to see how well this would work, > but because it regards links as separate from the linked objects, it got > too > complicated. But it could give a starting point if you have lots of such > cases. > > HTH > > Peter Kenny > > > Tim Mackinnon wrote > > Hey thanks guys - while it certainly makes sense when you think about it, > I was kind of hoping we had something that was much more readable and > obvious. It seems strange that when we have lots of esoteric things in > collection, that something which is quite common to do isnât there. I was > kind of hoping we might have some circular list or something. > > As it stands, if you really want to communicate this clearly you are > almost better off just doing, the more obvious: > > (Index := index - 1) = 0 ifTrue: [index := items size]. > > Anyway, an interesting one. > > Tim > > On 28 Mar 2019, at 16:55, Peter Kenny < > > > peter@.co > > > > wrote: > > > Tim > > I found myself puzzling as to *why* James's solution works. This longer > explanation helped me to understand. > > First, generalize moving forward to moving an arbitrary number of steps, > still with wrapping. > > ^list at: (index + move - 1 \\ size + 1 > > Second, realize that moving backward one step with wrapping is exactly > equivalent to moving forward (size - 1) steps - because of wrapping, a > move > of size steps is null. > > Finally, substitute move = size - 1. > > ^list at: (index + size - 2 \\ size + 1. > > This can of course easily generalize to backward moves of any size. > > HTH > > Peter Kenny > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > >

March 29, 2019