- Pharo-users - lists.pharo.org

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

by CÃ©drick BÃ©ler

> The core cause of the problems is that the current NameResolver is totally blocking, especially in failure cases, which gives a terrible experience. > > 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". > > The main scope was real internet access, not (possibly) limited internal network access. But that is a good point to think about. I totally agree on this point (and thanks again to push such network reliable dev). For my project (where I consider Internet as an optional connexion, the less trusted one btw.), this is number one priority to be have a Â« non-blocking way to test if the image has a working internet connection Â». As I see it, but this is conceptual. To have Internet, I either use: 1) a LAN in between with a gateway (which provides a WAN service) 2) an internal modem (GSM for instance) I focus on 1) meaning if I (re) connect to a (know) LAN, I know if it provides a gateway. Actually the access point/switch is another node in the system. So I kind of get around the problem. Still having a nice OS integration is important especially with all network interfaces we have (and I think that was a limitation of SSDP if I remember correctly what Henrik said). So +100 to you initiative guys :) >> Let's definitely talk. I hang out in the pharo discord group. :) >> >> >> holger > > I am only an occasional IM users, I more of an email guy. Not an expert as you, but definitely interested in such discussions. PharoDays ? This could include pushing SSDP from Henrik and maybe integrating Nouryâs (and others) dev on NetworkExtra ? My 2 cents, CÃ©drick > > Sven > > >

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

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

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

by Sven Van Caekenberghe

Holger, I'll write most of my comments inline. Yesterday I moved my code to https://github.com/svenvc/NeoDNS using Tonel format, to make it a bit easier to consume. I also did a couple of minor updates while going over the functionality. Note the 'my code' is in the package Net-Protocols-DNS-Experimental, which is using the object model in 'Net-Protocols-DNS-MessageFormat' (that already existed before, I just ported/cleaned it a little bit to my taste). Are you coming to the Pharo Days ? We could talk there. (More below) > On 28 Mar 2019, at 09:29, Holger Freyther <holger(a)freyther.de> wrote: > > > >> 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... Yeah, naming is always fun, isn't it ? >> 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? 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)". The core cause of the problems is that the current NameResolver is totally blocking, especially in failure cases, which gives a terrible experience. 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". The main scope was real internet access, not (possibly) limited internal network access. But that is a good point to think about. > ... 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 hacked a #getSystemDNS class method that goes via /etc/resolv.conf and it works (but of course not on Windows). In the 'initialise' protocol, there are #useCloudflareDNS, #useGoogleDNS, #useSystemDNS as well as #useMulticastDNS methods. I would *very* much prefer not to depend on any obscure, hard to maintain VM code (FFI would just be acceptable). > 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. 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). But yes, ultimately, things might be more complex. There is of course a problem in doing in-image DNS: it creates a (possibly) huge maintenance burden with a lot of responsibility. Now, since we already do socket streams, TLS/SSL and HTTP, the risk/challenge is probably acceptable. In any case, any solution would first need to prove itself in lots of real world situations. I actually added a #install class method to NeoDNSClient that hacks into the existing NetNameResolver and takes over responsibility for #addressForName:[timeout:] - for the whole image - of course this is still pure alpha. I am curious though, what was your initial motivation for starting PaleoDNS ? Which concrete issues did you encounter that you wanted to fix ? > Let's definitely talk. I hang out in the pharo discord group. :) > > > holger I am only an occasional IM users, I more of an email guy. Sven

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

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(a)pbkresearch.co.uk> 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 >

March 29, 2019

First Call for Papers: 12th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2019)

by Andrei Chis

------------------------------------------------------------------------ Call for Papers: 12th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2019) co-located with SPLASH 2019 Athens, Greece October 21-22, 2019 https://conf.researchr.org/home/sle-2019 http://www.sleconf.org/2019 Follow us on twitter: https://twitter.com/sleconf ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 12th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2019), held in conjunction with SPLASH 2019 at Athens, Greece on October 21-22, 2019. --------------------------- Topics of Interest --------------------------- SLE 2019 solicits high-quality contributions in areas ranging from theoretical and conceptual contributions, to tools, techniques, and frameworks in the domain of software language engineering. Topics relevant to SLE cover generic aspects of software languages development rather than aspects of engineering a specific language. In particular, SLE is interested in contributions from the following areas: * Software Language Design and Implementation - Approaches to and methods for language design - Static semantics (e.g., design rules, well-formedness constraints) - Techniques for specifying behavioral / executable semantics - Generative approaches (incl. code synthesis, compilation) - Meta-languages, meta-tools, language workbenches * Software Language Validation - Verification and formal methods for languages - Testing techniques for languages - Simulation techniques for languages * Software Language Integration and Composition - Coordination of heterogeneous languages and tools - Mappings between languages (incl. transformation languages) - Traceability between languages - Deployment of languages to different platforms * Software Language Maintenance - Software language reuse - Language evolution - Language families and variability * Domain-specific approaches for any aspects of SLE (design, implementation, validation, maintenance) * Empirical evaluation and experience reports of language engineering tools - User studies evaluating usability - Performance benchmarks - Industrial applications --------------------------- Important Dates --------------------------- All dates are Anywhere on Earth. * Fri 14 Jun 2019 - Abstract Submission * Fri 21 Jun 2019 - Paper Submission * Fri 9 Aug 2019 - Author Notification * Fri 16 Aug 2019 - Artifact Submission * Fri 30 Aug 2019 - Artifact Kick-the-tires Author Response (7 days) * Fri 20 Sep 2019 - Camera ready deadline * Wed 25 Sep 2019 - Artifact notification * Fri 27 Sep 2019 - Artifact-related paper updates * Mon-Tue 21-22 Oct 2018 - SLE Conference --------------------------- Types of Submissions --------------------------- SLE 2019 solicits three types of contributions: Research Papers, Tools Papers, and New Ideas/Vision papers. * Research papers These should report a substantial research contribution to SLE or successful application of SLE techniques or both. Full paper submissions must not exceed 12 pages, excluding bibliography. * Tool papers Because of SLEâs interest in tools, we seek papers that present software tools related to the field of SLE. Selection criteria include originality of the tool, its innovative aspects, and relevance to SLE. Any of the SLE topics of interest are appropriate areas for tool demonstrations. Submissions must provide a tool description of 4 pages excluding bibliography, and a demonstration outline including screenshots of up to 6 pages. Tool demonstrations must have the keywords âTool Demoâ or âTool Demonstrationâ in the title. The 4-page tool description will, if the demonstration is accepted, be published in the proceedings. The 6-page demonstration outline will be used by the program committee only for evaluating the submission. *New ideas / vision papers New ideas papers should describe new, non-conventional SLE research approaches that depart from standard practice. They are intended to describe well-defined research ideas that are at an early stage of investigation. Vision papers are intended to present new unifying theories about existing SLE research that can lead to the development of new technologies or approaches. New ideas / vision papers must not exceed 4 pages, excluding bibliography. *Workshops Workshops will be organized by SPLASH. Please inform us and contact the SPLASH organizers if you would like to organize a workshop of interest to the SLE audience. Information on how to submit workshops can be found at the SPLASH 2019 Website. --------------------------- Artifact Evaluation --------------------------- SLE will continue to use an evaluation process for assessing the quality of the artifacts on which papers are based to foster the culture of experimental reproducibility. Authors of accepted papers are invited to submit artifacts. For more information, please have a look at the Artifact Evaluation page. --------------------------- Submission Details --------------------------- Paper Format: Submissions must conform to the ACM SIGPLAN Conference Format âacmartâ; please make sure that you always use the latest ACM SIGPLAN acmart LaTeX template, and that the document class definition is \documentclass[sigplan,screen]{acmart}. Do not make any changes to this format! Using the Word template is strongly discouraged. Ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes in figures and tables are legible. To increase fairness in reviewing, a double-blind review process has become standard across SIGPLAN conferences. For the first time, SLE will follow the double-blind process. Author names and institutions should be omitted from submitted papers, and references to the authorsâ own related work should be in the third person. No other changes are necessary, and authors will not be penalized if reviewers are able to infer their identities in implicit ways. All submissions must be in PDF format. Concurrent Submissions: Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLANâs Republication Policy. Submitters should also be aware of ACMâs Policy and Procedures on Plagiarism. Submissions that violate these policies will be desk-rejected. Submission Site: Submissions will be accepted at https://sle19.hotcrp.com/ --------------------------- Reviewing Process --------------------------- All submitted papers will be reviewed by at least three members of the program committee. Research papers and tool papers will be evaluated concerning novelty, correctness, significance, readability, and alignment with the conference call. New ideas / vision papers will be evaluated primarily concerning novelty, significance, readability, and alignment with the conference call. For fairness reasons, all submitted papers must conform to the above instructions. Submissions that violate these instructions may be rejected without review, at the discretion of the PC chairs. --------------------------- Awards --------------------------- * Distinguished paper: Award for most notable paper, as determined by the PC chairs based on the recommendations of the programme committee. * Distinguished reviewer: Award for distinguished reviewer, as determined by the PC chairs. * Distinguished artifact: Award for the artifact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artifact evaluation committee. --------------------------- Publication --------------------------- All accepted papers will be published in the ACM Digital Library. AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. --------------------------- Organisation --------------------------- Chairs: * General chair: Oscar Nierstrasz (University of Bern, Switzerland) * Program co-chair: Bruno Oliveira (University of Hong Kong, China) * Program co-chair: Jeff Gray (University of Alabama, USA) * Artefact Evaluation co-chair: Emma SÃ¶derberg (Lund University, Sweden) * Artefact Evaluation co-chair: Abel Gomez (Universitat Oberta de Catalunya, Spain) Program Committee: Xuan Bi (Standard Chartered Bank) Erwan Bousse (TU Wien) Loli Burgeuno (Open University of Catalonia) Marsha Chechik (University of Toronto) Matteo Cimini (University of Massachusetts, Lowell) Thomas Degueule (CWI) Juan de Lara (Universidad AutÃ³noma de Madrid) Juergen Dingel (Queen's University) Romina Eramo (University of L'Aquila) Sebastian Gerard (CEA) Paolo Giarusso (TU Delft) Esther Guerra (Universidad AutÃ³noma de Madrid) Pablo Inostroza (CWI) Dimitris Kolovos (University of York) Marjan Mernik (University of Maribor) Alfonso Pierantonio (University of L'Aquila) Jaroslav PorubÃ¤n (University of KoÅ¡ice) Casper Poulsen (TU Delft) Yann Regis-Gianas (Paris 7/INRIA) Bernhard Rumpe (RWTH Aachen University) Markus Schordan (Lawrence Livermore National Laboratory) Neil Sculthorpe (Nottingham Trent University) Marco Servetto (Victoria University of Wellington) Elizabeth Scott (Royal Holloway) Eugene Syriani (University of Montreal) Ulyana Tikhonova (CWI) Juha-Pekka Tolvanen (MetaCase) Antonio Valecillo (University of Malaga) Mark van den Brand (TU Eindhoven) Vadim Zaytsev (Raincode Labs) Tian Zhang (Nanjing University) --------------------------- Contact --------------------------- For additional information, clarification, or answers to questions, please contact the organizers by email (bruno(a)cs.hku.hk and gray(a)cs.ua.edu)

March 29, 2019

Re: [Pharo-users] Any desire to have/adapt ClyBrowserMorph>>#confirmDiscardChanges to be a little more informative?

by Richard Sargent

On March 28, 2019 7:24:25 PM PDT, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: >Paul DeBruicker wrote >> Right now with Calypso... I have a hard time seeing or remembering >what >> its even talking about. > >Me too. One of the things I most love about Smalltalk is the ability to get our hands on the real objects. And perhaps my greatest frustration is that the implementations make that harder to do. Ideally, every UI would have a "what are you talking about" mechanism that would let us move past the high-level (and inherently limiting) GUI and get our hands on the underlying model. > > >Paul DeBruicker wrote >> I'd be particularly interested in seeing diffs between the pre-edited >> version and current. > >That would be super cool! > > > >----- >Cheers, >Sean >-- >Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 29, 2019

Re: [Pharo-users] Any desire to have/adapt ClyBrowserMorph>>#confirmDiscardChanges to be a little more informative?

by Sean P. DeNigris

Paul DeBruicker wrote > Right now with Calypso... I have a hard time seeing or remembering what > its even talking about. Me too. Paul DeBruicker wrote > I'd be particularly interested in seeing diffs between the pre-edited > version and current. That would be super cool! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 29, 2019

Any desire to have/adapt ClyBrowserMorph>>#confirmDiscardChanges to be a little more informative?

by PAUL DEBRUICKER

Right now with Calypso I often have so many windows open with multiple tabs that when it asks me if I want to discard changes I have a hard time seeing or remembering what its even talking about. Would it be hard to change it from a simple confirmation to a diff viewer of some kind with DiffMorph? I'd be particularly interested in seeing diffs between the pre-edited version and current. If that were a thing that were developed would it be integrated or not? Thanks

March 28, 2019

Re: Zinc and Oauth2

by Davide Varvello

Thanks Sven, I'm going to give it a glance. Cheers Davide Sven Van Caekenberghe-2 wrote > Davide, > > The main Zinc repository is now https://github.com/svenvc/zinc (although > the old ones are also still good). > > You should look at the baseline, but loading group SSO will get you > started. > > I am not actively using OAuth, but several people have, so it should work > (the code did not change in a long while). > > This is not such a simple subject though (there are several demos that > used to work). > > Good luck, > > Sven > >> On 28 Mar 2019, at 20:54, Davide Varvello via Pharo-users < > pharo-users@.pharo > > wrote: >> >> >> From: Davide Varvello < > varvello@ > > >> Subject: Zinc and Oauth2 >> Date: 28 March 2019 at 20:54:05 GMT+1 >> To: > pharo-users@.pharo >> >> >> Hi Guys, >> I'm trying to play with Outh2, but I'm wondering how to download it in >> Pharo. >> >> If I use the Gofer as indicated here: >> https://github.com/svenvc/docs/blob/master/zinc/zinc-sso-paper.md >> >> Gofer it >> url: 'http://mc.stfx.eu/ZincHTTPComponents'; >> package: 'ConfigurationOfZincHTTPComponents'; >> load. >> ConfigurationOfZincHTTPComponents project latestVersion load: 'SSO'. >> >> >> It returns an error. >> 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

March 28, 2019