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

Re: [Pharo-users] json parse problem

by Ben Coman

On Sat, 16 Mar 2019 at 04:21, Roelof Wobben <r.wobben(a)home.nl> wrote: > Hello, > > I try to parse a json that differs some times > > after parsing with neojson I see something like this > > "an Array(a Dictionary('height'->3640 'name'->'z0' 'tiles'->an Array(a Dictionary('url'->'http://lh3...TItQ4wwXk80sCHkqSS3JgTgmehYP-OItkO4hMwqH1agr-LfNRnxUCRSJKc_VQ=…' 'x'->0 'y'->0 )) 'width'->404 ))" > > > is there a way I can filter out a dictonary where the name is equal to z4 > > Because of cultural differences, I'm not sure by "filter out" whether you mean include or exclude but when filtering any collection type, #select: #detect and #reject: are you main go to messages. If you inspect your dictionary and on the meta tab filter for ...*select*... you'll find #associationsSelect: which works like this... d := Dictionary newFromPairs: #( 1 2 3 4 5 6 ). d associationsSelect: [ :asn | (asn key = 1) and: (asn value = 2) ] d inspect. ==> Dictionary [1 item] (1->2 ) I notice there is not a similar #associationsReject: so if needed you could add your own considering... d := Dictionary newFromPairs: #( 1 2 3 4 5 6 ). d associations select: [ :asn | (asn key = 1) and: (asn value = 2) ] d inspect. ==> Array [1 item] (1->2) d := Dictionary newFromPairs: #( 1 2 3 4 5 6 ). d associations reject: [ :asn | (asn key = 1) and: (asn value = 2) ] d inspect. ==> Array [2 items] (5->6 3->4) cheers -ben

March 16, 2019

7.0.2 and the font glitch - seems far worse than 7.0.1

by Tim Mackinnon

Moving this to a new thread - to avoid historic confusion as Iâm seeing a much clearer pattern now. In 7.0.1 (osx - high Sierra - launcher), I was seeing the odd font glitch (where characters suddenly start glyphing in code and menus - see photos) and it seemed to be fixable by saving your image the first time (e.g. after 30+ mins you would see this in a new install). Once the image was saved, this seemed to stick and never be a problem. In 7.0.2 this is now happening to me very 10-60 mins. The save fix still works - the moment you save the glyphs will all just disappear until it happens again. Is anyone else getting this so easily in 7.0.2 (are others using 7.0.2). Has something changed in 7.0.2 that would cause this (the change list was quite small - however its noted the welcome screen is broken in this build too , so maybe that is related)? My image is actually pretty small - just load Exercism , which relies on OSProcess, now Mocketry (with StateSpecs and Ghost) and in this occurrence I have also loaded Mirage (the lack of a decent keyboard window switcher was getting me down and mirage seems to nail that MRU style behaviour to switch between a test window and code window). It could be one of these things is the culprit (potentially mirage - as that is the newest edition, so I will create a new image and leave it out) - but wondering if others are seeing this? Or possibly Iâve found the right combination that reliably triggers this annoying issue. Tim

March 15, 2019

Re: [Pharo-users] Calypso openOnGroup?

by Denis Kudriashov

Hello Hernan. Try following example: ClyFullBrowser openWithState: [:browser | browser selectClass: Announcer atMethodTag: #initialization ] Ð²Ñ, 12 Ð¼Ð°Ñ. 2019 Ð³. Ð² 02:43, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com >: > Hi, > > Is there any way to open a browser on a method group in Claypso? > > This was possible in Nautilus: > > Smalltalk tools browser > openOnCategory: #compiling > ofClass: Class > > Cheers, > > HernÃ¡n > >

March 15, 2019

Why doesn't collection have #excludes (the mirror of includes)?

by Tim Mackinnon

Hi - in my quest to understand the edgier details of Pharo (and Smalltalk) - and driven by fresh thoughts of completing exercism exercises - I was surprised to find that there is no #excludes: operation on collection to mirror the #includes: operation? I was curious about this - its seems a strange omission? Of course I can inverse it with not, or do things a different way - but we have ifTrue: mirrored with ifFalse, empty/notEmpty so am I missing something? I wanted to write something like aString detect: [:c | ($0 to: $1) excludes: c] ifFound: aBlock. (Evaluate a block if the string isnât all 0 and 1âs) Of course I can write this as: (aString reject: [:c | c = $0 | c = $1)) ifNotEmpty: aBlock But as recent messages in this vein have shown me (and taught me lots - thanks to those answering), the answer is often not what I thought. Tim

March 15, 2019

Re: [Pharo-users] TelePharo in Tonel

by Denis Kudriashov

Hi Torsten. It requires finally merging branch with network discovery tool. Otherwise it would be a pain to do it after conversion. The branch provides a Radar tool to discover available images in the network. Generally it works but it needs real live testing. Some logic of server connection was refactored to achieve it and it needs real tests. Also it adds new dependency to SSDP library which is currently managed by smalltalkhub. It would be nice to move it into github. But it needs to be in sync with the author (Henrik Johansen). Ð²Ñ, 12 Ð¼Ð°Ñ. 2019 Ð³., 20:20 Torsten Bergmann <astares(a)gmx.de>: > Hi Denis, > > would it be possible to convert TelePharo to Tonel? > > https://github.com/pharo-ide/TelePharo > > Currently one gets load problem on Windows due to long file names and > Tonel would > solve that. > > Thanks > T. >

March 15, 2019

json parse problem

by Roelof Wobben

March 15, 2019

Re: [Pharo-users] Per project code formatting settings and policy

by Sean P. DeNigris

Holger Freyther wrote > What I didn't see is if a project can supply the style (instead of the > image configuration) Great idea!! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 15, 2019

GPCE 2019: 1st Call for Papers - Athens, Greece; October 21-22

by Rodin Aarssen

CALL FOR PAPERS 18th International Conference on Generative Programming: Concepts & Experiences (GPCE 2019) October 21-22, 2019 Athens, Greece (co-located with SPLASH 2019) https://conf.researchr.org/home/gpce-2019 http://twitter.com/GPCECONF http://www.facebook.com/GPCEConference IMPORTANT DATES * Submission of abstracts: June 14, 2019 * Submission of papers: June 21, 2019 * Paper notification: August 9, 2019 Submission site: https://gpce19.hotcrp.com/ -------------------------------------------------------------------------- SCOPE GPCE is a venue for researchers and practitioners interested in techniques and tools for code generation, language implementation, and metaprogramming. GPCE seeks conceptual, theoretical, empirical, and technical contributions to its topics of interest, which include but are not limited to: * program transformation, staging, macro systems, preprocessors, program synthesis, and code-recommendation systems, * domain-specific languages, language embedding, language design, and language workbenches, * feature-oriented programming, domain engineering, and feature interactions, * applications and properties of code generation, language implementation, and product-line development. Authors are welcome to check with the program co-chairs whether their planned papers are in scope. PAPER SELECTION The GPCE program committee will evaluate each submission according to the following selection criteria: * Novelty. Papers must present new ideas or evidence and place them appropriately within the context established by previous research in the field. * Significance. The results in the paper must have the potential to add to the state of the art or practice in significant ways. * Evidence. The paper must present evidence supporting its claims. Examples of evidence include formalizations and proofs, implemented systems, experimental results, statistical analyses, and case studies. * Clarity. The paper must present its contributions and results clearly. PAPER CATEGORIES GPCE solicits three kinds of submissions. * Full Papers reporting original and unpublished results of research that contribute to scientific knowledge in any GPCE topic listed above. Full paper submissions must not exceed 12 pages excluding bibliography. * Short Papers presenting unconventional ideas or visions about any GPCE topic listed above. Short papers do not always require complete results as in the case of a full paper. In this way, authors can introduce new ideas to the community and get early feedback. Please note that short papers are not intended to be position statements. Short papers are included in the proceedings and will be presented at the conference. Short paper submissions must not exceed 6 pages excluding bibliography. * Tool Demonstrations presenting tools for any GPCE topic listed above. Tools must be available for use and must not be purely commercial. Submissions must provide a tool description not exceeding 6 pages excluding bibliography and a separate demonstration outline including screenshots also not exceeding 6 pages. Tool demonstrations must have the keywords "Tool Demo" or "Tool Demonstration" in their title. If the submission is accepted, the tool description will be published in the proceedings. The demonstration outline will only be used by the program committee for evaluating the submission. PAPER SUBMISSION All submissions must use the ACM SIGPLAN Conference Format "acmart", using the "sigplan" sub-format, and 10 point font. Additional details and links to templates and the LaTeX class file can be found on the conference web site: https://conf.researchr.org/home/gpce-2019. To increase fairness in reviewing, a double-blind review process has become standard across SIGPLAN conferences. GPCE will follow a very lightweight model, where author identities are revealed to reviewers after submitting their initial reviews. Hence, the purpose is not to conceal author identities at all cost, but merely to provide reviewers with an unbiased first look at a submission. 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. Papers must be submitted using HotCRP: https://gpce19.hotcrp.com/ For additional information, clarification, or answers to questions please contact the program co-chairs. ORGANIZATION Chairs * General chair: Ina Schaefer (TU Braunschweig) * Program co-chair: Christoph Reichenbach (Lund University) * Program co-chair: Tijs van der Storm (CWI / University of Groningen) Program Committee * Jonathan Aldrich (CMU) * Juliana Alves Pereira (University Rennes) * Marsha Chechik (University of Toronto) * Shigeru Chiba (University of Tokyo) * Thomas Degueule (CWI) * Sebastian Erdweg (TU Delft) * Matthew Flatt (University of Utah) * Robert GlÃ¼ck (University of Copenhagen) * Elisa Gonzalez Boix (VUB) * Geoffrey Mainland (Drexel University) * Chris Martens (NCSU) * Maryam Mehri Dehnavi (University of Toronto) * Peter Mosses (Swansea University / TU Delft) * David Pearce (Victoria University of Wellington) * Alex Potanin (Victoria University of Wellington) * Larissa Rocha Soares (Federal University of Bahia) * Ulrik Schultz (University of Southern Denmark) * Sandro Schulze (University of Magdeburg) * Christoph Seidl (TU Braunschweig) * Michel Steuwer (University of Glasgow) * Sam Tobin Hochstadt (Indiana University) * Kanae Tsushima (National Institute of Informatics) * Philip Wadler (University of Edinburgh) * Eric Walkingshaw (Oregon State University) * Adam Welc (Uber) * Peng Wu (Huawei)

March 15, 2019

Re: [Pharo-users] Per project code formatting settings and policy

by Marcus Denker

> On 15 Mar 2019, at 08:48, Holger Freyther <holger(a)freyther.de> wrote: > > Hi! > > I found myself doing codereview and commenting on style (e.g. missing indention). It seems like a task that can be easily automated and in fact we have RBFormmatter/BlueInk to do it. > > What I didn't see is if a project can supply the style (instead of the image configuration)? \\ > How could this be achieved? > That would be really nice! Right now it uses global Preferences. We should check how much work it would be to allow the global setup to be overridden per Class and per Packageâ¦ This would need some refactoring, thoughâ¦ the settings are already localised in the BIPrettyPrinterContext class. There is one instance in the class var DefaultPrettyPrintContext in the main pretty printer class. We would need some way to do this *per instance* of the pretty printer and then set it when creating the pretty printer, asking the class and the manifest for a PrettyPrintContext before setting the defaultâ¦ Marcus

March 15, 2019

Re: [Pharo-users] Per project code formatting settings and policy

by Ben Coman

On Fri, 15 Mar 2019 at 15:56, Holger Freyther <holger(a)freyther.de> wrote: > Hi! > > I found myself doing codereview and commenting on style (e.g. missing > indention). It seems like a task that can be easily automated and in fact > we have RBFormmatter/BlueInk to do it. > > What I didn't see is if a project can supply the style (instead of the > image configuration)? How could this be achieved? > > That would be a nice feature, if it is not already. cheers -ben

March 15, 2019