- Pharo-users - lists.pharo.org

Re: [Pharo-users] Smalltalk-Bolivia at ICSE SRC 2019

by Guillermo Polito

Super news :) congratulations! > El 4 jun 2019, a las 19:42, Ben Coman <btc(a)openinworld.com> escribiÃ³: > > This is really great to hear people's success. Thanks for sharing. > cheers -ben > > On Wed, 5 Jun 2019 at 00:34, Juan Pablo Sandoval Alcocer <juampiboy(a)gmail.com <mailto:juampiboy@gmail.com>> wrote: > Hi, > > We would like to share good news from Bolivia. Our student Alejandra Siles participated in the ICSE Student Research Competition (Undergrad category). She present a tool called TOAD, which is a tool for recommending source code selection alternatives for the extract method refactoring. TOAD was developed in Pharo. You may find the prototype on http://smalltalkhub.com/#!/~juampi/Toad <http://smalltalkhub.com/#!/~juampi/Toad> > > Alejandra was selected by the ACM SRC (Student Research Competition) as the best undergrad student. After 3 rounds (writing a short paper, writing and defending a poster, and presenting her results), she finished 1st in the undergrad category. This is a fantastic results that really show the quality of the research being done in Bolivia. You might find some pictures in the attached files. > > Regards, > Juan Pablo Sandoval A. > jpsandoval.github.io <http://jpsandoval.github.io/> > > <IMG_6322.jpeg>

June 5, 2019

Re: [Pharo-users] Smalltalk-Bolivia at ICSE SRC 2019

by Ben Coman

This is really great to hear people's success. Thanks for sharing. cheers -ben On Wed, 5 Jun 2019 at 00:34, Juan Pablo Sandoval Alcocer < juampiboy(a)gmail.com> wrote: > Hi, > > We would like to share good news from Bolivia. Our student Alejandra Siles > participated in the ICSE Student Research Competition (Undergrad category). > She present a tool called TOAD, which is a tool for recommending source > code selection alternatives for the extract method refactoring. TOAD was > developed in Pharo. You may find the prototype on > http://smalltalkhub.com/#!/~juampi/Toad > > Alejandra was selected by the ACM SRC (Student Research Competition) as > the best undergrad student. After 3 rounds (writing a short paper, writing > and defending a poster, and presenting her results), she finished 1st in > the undergrad category. This is a fantastic results that really show the > quality of the research being done in Bolivia. You might find some pictures > in the attached files. > > Regards, > Juan Pablo Sandoval A. > jpsandoval.github.io > > [image: IMG_6322.jpeg] >

June 4, 2019

Smalltalk-Bolivia at ICSE SRC 2019

by Juan Pablo Sandoval Alcocer

Hi, We would like to share good news from Bolivia. Our student Alejandra Siles participated in the ICSE Student Research Competition (Undergrad category). She present a tool called TOAD, which is a tool for recommending source code selection alternatives for the extract method refactoring. TOAD was developed in Pharo. You may find the prototype on http://smalltalkhub.com/#!/~juampi/Toad Alejandra was selected by the ACM SRC (Student Research Competition) as the best undergrad student. After 3 rounds (writing a short paper, writing and defending a poster, and presenting her results), she finished 1st in the undergrad category. This is a fantastic results that really show the quality of the research being done in Bolivia. You might find some pictures in the attached files. Regards, Juan Pablo Sandoval A. jpsandoval.github.io [image: IMG_6322.jpeg]

June 4, 2019

Second 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,anonymous,review]{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)

June 4, 2019

Re: [Pharo-users] Block/Brick

by Steve Quezadas

Glenn, Thank you for your response. Ok, so you can browse examples by inspecting the class? Which classes do you mean because I can't seem to find any ones with examples. For example, here: https://steverstuff.s3.amazonaws.com/pharo2.png I can't find the examples tag! Maybe I am looking in the wrong package. I am looking under the classes of package "Brick". Do you know what objects, specifically, that has an Examples tab? On Tue, May 7, 2019 at 3:53 AM Glenn CavarlÃ© <glenn.cavarle(a)gmail.com> wrote: > H Steve, > > I just saw that you sent me a personal email about that. > Thanks for your interest in Brick, I have been slightly away from the > project for some time so maybe Aliaksei or Doru could provide a better > answer. > > For my part, since Brick is using GtExample, I'm just browsing examples by > inspecting the class. > When the inspector is open, you can browse and show examples in the tab > named "Examples". > > > test email wrote > > PS Is Brick/Block the thing to learn these days? Is this where > development > > is heading? > > Good question. > There are 2 actively developed projects : Spec2 and Bloc/Brick. > Some fresh info here: > > http://forum.world.st/Explaining-Spec2-and-why-Bloc-is-on-the-roadmap-td509… > > > Spec (https://github.com/pharo-spec/Spec) is a UI Builder which aim to be > backend-independent. > All "native" tools shipped in the Pharo image are developped using it (or > should be). > A new version is actively developed and already show great results. Spec2 > should probably support Bloc/Brick as backend in the near future. > > Brick is a redesigned widget layer on top of Bloc, a new UI infrastructure > which aim to replace Morphic, one day. > The original github repo is https://github.com/pharo-graphics/Brick but I > saw that the Feenk team (which actively develop it) forked the repo in > Febrary (https://github.com/feenkcom/Brick) > So i don't know what is exactly the current state of each version. > > I hope I have answered your questions ;) > Cheers, > > > > ----- > Glenn CavarlÃ© > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

June 4, 2019

Re: [Pharo-users] ODBCDriver

by TomaÅ¾ Turk

I see - thanks! Best wishes, Tomaz ------ Original Message ------ From: "JuliÃ¡n Maestri" <serpi90(a)gmail.com> To: "TomaÅ¾ Turk" <tomaz.turk(a)ef.uni-lj.si>; "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Sent: 3.6.2019 16:03:25 Subject: Re: [Pharo-users] ODBCDriver >As far as I know, he just started porting it to Pharo 7. > >On Sun, Jun 2, 2019, 13:51 TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> wrote: >>I just found this marvel: https://github.com/apiorno/ODBCDriver. >> >>But when I try to >> >>| con | >>con := ODBCConnection dsn:'myDSN' user:'usr' password:'pwd'. >> >>it responds with an error "Instance of ODBCLibrary class did not >>understand #sqlAllocEnv": >> >> >>running on Win 10 and Pharo 7.0.3. I'd appreciate any help. >> >>Best wishes, >>Tomaz >> >>

June 3, 2019

Re: [Pharo-users] Find after in strings?

by Tim Mackinnon

Would it be really bad to use the deprecation feature in Pharo to gently migrate to a more common name in stream? There are 101 senders of match: (in my P7 image - presumably some of them my usage), and a lot of them actually referring to string regex match:. Its big but not immense. #match: normally has the connotation with the String regex matching, not stream skipping, so it might not be too bad (in my mind, and hence why I was a bit caught out - although having some equivalent in a string would be handy too). The deprecation mechanism over time would begin to convert them over from sheer usage wouldnât it? How do we decide such things? Is there some proposal mechanism? Tim > On 3 Jun 2019, at 15:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > To each his own opinion, #match: is not that bad a name, IMHO. > > There is much more bloat than the mixing of reading and writing. > > The concept of being positionable is bad too: it makes no sense for network and other non-collection backed streams. > > There is also all the binary, encoding and converting API that assumes a specific type of element, an assumption that is not always correct. > > Yes, Traits could help, but all this is a lot of work. > > And I feel like this is a lost battle: everybody keeps on asking to put his/her favourite methods back. > >> On 3 Jun 2019, at 00:20, Richard O'Keefe <raoknz(a)gmail.com> wrote: >> >> The issue is that #skipToAll: is the de facto standard name for the >> operation EXCEPT in Squeak and Pharo. It's not that an alias should >> be added. What should *really* be done is that #match: should be >> *renamed* to #skipToAll:. This will >> - improve compatibility >> - reduce confusion >> - improve navigability >> >> At the moment, for example, it is much harder to discover the >> consequences of renaming the #match: method than it should be >> because not just people but the system itself confuses #match: >> with #match:. >> >> The *real* API bloat in PositionableStream is that it covers >> both positionable input streams (which can implement #skipToAll:) >> and positionable output streams (which cannot), so that there >> are way too many methods in the interface of a WriteStream that >> cannot possibly work in any state of the receiver. >> >> With Trait support in Pharo, it is long past time that ReadStreams >> (and files opened for input only) did not respondTo: #nextPut: and >> that WriteStreams (and files opened for output only) did not >> respondTo: #next. >> >> THAT bloat dwarfs a compatibility method. >> >> >> On Mon, 3 Jun 2019 at 03:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Why add an alias ? The API is too wide as it is already. >> >> Note that most current implementations of #upToAll: already use words like match, so #match: is not that crazy. >> >> Yes it should be possible to talk about naming, but just adding aliases, no. >> >> My opinion, of course. >> >>> On 2 Jun 2019, at 04:33, Richard O'Keefe <raoknz(a)gmail.com> wrote: >>> >>> skipToAll: aCollection >>> "Set the receiver's position to just after the next occurrence of aCollection >>> in the receiver's future values and answer true. If there is no such >>> occurrence, answer false. In either case, left the postion where #upToAll: >>> would have left it." >>> ^self match: aCollection >>> >>> Sorry about the incomplete message. >>> #match: is such a bad name for this operation that the method comment has to >>> go to some trouble to explain that it is nothing like #match: for Strings. >>> >>> >>> On Sun, 2 Jun 2019 at 14:29, Richard O'Keefe <raoknz(a)gmail.com> wrote: >>> To get #skipToAll: in Pharo, add this to PositionableStream. >>> >>> skipToAll: aCollection >>> "Set the receiver's to just after the next occcurrence of aCollection >>> in the receiver's future values and answer true. If there is no such >>> >>> >>> On Sun, 2 Jun 2019 at 07:50, Tim Mackinnon <tim(a)testit.works> wrote: >>> Interesting - there is no #skipToAll: in pharo, I wonder why not? It sounds like what I was looking for - and Iâm surprised its not there. There is #skipTo: for an object (which sounds right, just not the string equivalent). >>> >>> Iâm not doing anything special, just want to take some lines from the end of a class comment and use them in an exercism exercise - but its not different than many applications - find some tag and use the text after it. Iâm kind of surprised its not in Pharo. >>> >>> Tim >>> >>> >>>> On 1 Jun 2019, at 12:25, Richard O'Keefe <raoknz(a)gmail.com> wrote: >>>> >>>> If you want to move around in strings, you might want to use a ReadStream. >>>> In some Smalltalk systems there is a method called #skipToAll:. >>>> Here's how mine starts out: >>>> >>>> skipToAll: aSequence >>>> "If the remaining elements can be parsed as <a><aSequence><b>, >>>> return true leaving the position where? Otherwise return false. >>>> GNU Smalltalk, Dolphin, and VisualAge: >>>> leave the position after <aSequence>, consistent with #upToAll:, >>>> and implementable in this class. (GST uses the KMP algorithm.) >>>> VisualWorks and ST/X: >>>> leave the position before <aSequence>, inconsistent with #upToAll:, >>>> and only implementable for positionable streams. >>>> Squeak 5.2 and Pharo 6.0: >>>> not provided. >>>> I cannot be compatible with everything. The semantics of >>>> #skipToAll: should obviously match #upToAll:, so I'll fit >>>> in with GNU, Dolphin, and VisualAge Smalltalk. >>>> " >>>> >>>> So >>>> (myReadStream skipToAll: 'marker') >>>> ifTrue: [loc := myReadStream position] >>>> ifFalse: [alternative code]. >>>> >>>> HOWEVER, I have a bad feeling about this. The entire approach, as with much >>>> concerning strings in a Unicode age, seems fraught with peril. Consider >>>> input = 'the need for vigilance is never-ending' >>>> marker = 'end' >>>> Should the marker be found or not? >>>> input = '.... Si<floating acute accent> ...' >>>> marker = 'Si' >>>> Should the marker be found or not? >>>> My code is NOT sensitive to these issues. >>>> I would like to say that it was because I was writing a compatibility >>>> method, so my code was compatibly broken, >>>> but to be honest, I was stupid and forgot to think it through. >>>> I would think that there would need to be an '... asTokens: aBoolean' >>>> variant that checks that a match >>>> - is not followed by floating diacriticals >>>> - is not preceded by an alphanumeric if the target begins with one >>>> - is not followed by an alphanumeric if the target ends with one. >>>> >>>> My own preference is to write a lexical analyser for the mini-language >>>> I'm using, and NOT try to hack at it using general-purpose string >>>> methods. >>>> >>>> Perhaps you can tell us more about the context? What is the application- >>>> level task you are trying to solve? >>>> >>>> >>>> >>>> On Sat, 1 Jun 2019 at 22:01, Tim Mackinnon <tim(a)testit.works> wrote: >>>> Maybe this is a dumb question - and often Iâm surprised when asking these, but why is there no way to âfind afterâ a string. >>>> >>>> I find it rather boring to try and parse a string, after a known marker - thus: >>>> (loc := aString findString: âmarkerâ) > 0 ifTrue: [ loc := loc + âmarkerâ size ]. >>>> >>>> Is there a better way? This whole pattern seems very old and clunky and not smalltalk like? >>>> >>>> Couldnât we have: findAfter: aString ifAbsent: aBlock ? >>>> >>>> Or is there a whole better pattern for string searching that Iâm missing ? >>>> >>>> Tim >>> >> >> > >

June 3, 2019

Re: [Pharo-users] Find after in strings?

by Sven Van Caekenberghe

To each his own opinion, #match: is not that bad a name, IMHO. There is much more bloat than the mixing of reading and writing. The concept of being positionable is bad too: it makes no sense for network and other non-collection backed streams. There is also all the binary, encoding and converting API that assumes a specific type of element, an assumption that is not always correct. Yes, Traits could help, but all this is a lot of work. And I feel like this is a lost battle: everybody keeps on asking to put his/her favourite methods back. > On 3 Jun 2019, at 00:20, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > The issue is that #skipToAll: is the de facto standard name for the > operation EXCEPT in Squeak and Pharo. It's not that an alias should > be added. What should *really* be done is that #match: should be > *renamed* to #skipToAll:. This will > - improve compatibility > - reduce confusion > - improve navigability > > At the moment, for example, it is much harder to discover the > consequences of renaming the #match: method than it should be > because not just people but the system itself confuses #match: > with #match:. > > The *real* API bloat in PositionableStream is that it covers > both positionable input streams (which can implement #skipToAll:) > and positionable output streams (which cannot), so that there > are way too many methods in the interface of a WriteStream that > cannot possibly work in any state of the receiver. > > With Trait support in Pharo, it is long past time that ReadStreams > (and files opened for input only) did not respondTo: #nextPut: and > that WriteStreams (and files opened for output only) did not > respondTo: #next. > > THAT bloat dwarfs a compatibility method. > > > On Mon, 3 Jun 2019 at 03:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Why add an alias ? The API is too wide as it is already. > > Note that most current implementations of #upToAll: already use words like match, so #match: is not that crazy. > > Yes it should be possible to talk about naming, but just adding aliases, no. > > My opinion, of course. > > > On 2 Jun 2019, at 04:33, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > skipToAll: aCollection > > "Set the receiver's position to just after the next occurrence of aCollection > > in the receiver's future values and answer true. If there is no such > > occurrence, answer false. In either case, left the postion where #upToAll: > > would have left it." > > ^self match: aCollection > > > > Sorry about the incomplete message. > > #match: is such a bad name for this operation that the method comment has to > > go to some trouble to explain that it is nothing like #match: for Strings. > > > > > > On Sun, 2 Jun 2019 at 14:29, Richard O'Keefe <raoknz(a)gmail.com> wrote: > > To get #skipToAll: in Pharo, add this to PositionableStream. > > > > skipToAll: aCollection > > "Set the receiver's to just after the next occcurrence of aCollection > > in the receiver's future values and answer true. If there is no such > > > > > > On Sun, 2 Jun 2019 at 07:50, Tim Mackinnon <tim(a)testit.works> wrote: > > Interesting - there is no #skipToAll: in pharo, I wonder why not? It sounds like what I was looking for - and Iâm surprised its not there. There is #skipTo: for an object (which sounds right, just not the string equivalent). > > > > Iâm not doing anything special, just want to take some lines from the end of a class comment and use them in an exercism exercise - but its not different than many applications - find some tag and use the text after it. Iâm kind of surprised its not in Pharo. > > > > Tim > > > > > >> On 1 Jun 2019, at 12:25, Richard O'Keefe <raoknz(a)gmail.com> wrote: > >> > >> If you want to move around in strings, you might want to use a ReadStream. > >> In some Smalltalk systems there is a method called #skipToAll:. > >> Here's how mine starts out: > >> > >> skipToAll: aSequence > >> "If the remaining elements can be parsed as <a><aSequence><b>, > >> return true leaving the position where? Otherwise return false. > >> GNU Smalltalk, Dolphin, and VisualAge: > >> leave the position after <aSequence>, consistent with #upToAll:, > >> and implementable in this class. (GST uses the KMP algorithm.) > >> VisualWorks and ST/X: > >> leave the position before <aSequence>, inconsistent with #upToAll:, > >> and only implementable for positionable streams. > >> Squeak 5.2 and Pharo 6.0: > >> not provided. > >> I cannot be compatible with everything. The semantics of > >> #skipToAll: should obviously match #upToAll:, so I'll fit > >> in with GNU, Dolphin, and VisualAge Smalltalk. > >> " > >> > >> So > >> (myReadStream skipToAll: 'marker') > >> ifTrue: [loc := myReadStream position] > >> ifFalse: [alternative code]. > >> > >> HOWEVER, I have a bad feeling about this. The entire approach, as with much > >> concerning strings in a Unicode age, seems fraught with peril. Consider > >> input = 'the need for vigilance is never-ending' > >> marker = 'end' > >> Should the marker be found or not? > >> input = '.... Si<floating acute accent> ...' > >> marker = 'Si' > >> Should the marker be found or not? > >> My code is NOT sensitive to these issues. > >> I would like to say that it was because I was writing a compatibility > >> method, so my code was compatibly broken, > >> but to be honest, I was stupid and forgot to think it through. > >> I would think that there would need to be an '... asTokens: aBoolean' > >> variant that checks that a match > >> - is not followed by floating diacriticals > >> - is not preceded by an alphanumeric if the target begins with one > >> - is not followed by an alphanumeric if the target ends with one. > >> > >> My own preference is to write a lexical analyser for the mini-language > >> I'm using, and NOT try to hack at it using general-purpose string > >> methods. > >> > >> Perhaps you can tell us more about the context? What is the application- > >> level task you are trying to solve? > >> > >> > >> > >> On Sat, 1 Jun 2019 at 22:01, Tim Mackinnon <tim(a)testit.works> wrote: > >> Maybe this is a dumb question - and often Iâm surprised when asking these, but why is there no way to âfind afterâ a string. > >> > >> I find it rather boring to try and parse a string, after a known marker - thus: > >> (loc := aString findString: âmarkerâ) > 0 ifTrue: [ loc := loc + âmarkerâ size ]. > >> > >> Is there a better way? This whole pattern seems very old and clunky and not smalltalk like? > >> > >> Couldnât we have: findAfter: aString ifAbsent: aBlock ? > >> > >> Or is there a whole better pattern for string searching that Iâm missing ? > >> > >> Tim > > > >

June 3, 2019

Re: [Pharo-users] ODBCDriver

by JuliÃ¡n Maestri

As far as I know, he just started porting it to Pharo 7. On Sun, Jun 2, 2019, 13:51 TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> wrote: > I just found this marvel: https://github.com/apiorno/ODBCDriver. > > But when I try to > > | con | > con := ODBCConnection dsn:'myDSN' user:'usr' password:'pwd'. > > it responds with an error "Instance of ODBCLibrary class did not > understand #sqlAllocEnv": > > > running on Win 10 and Pharo 7.0.3. I'd appreciate any help. > > Best wishes, > Tomaz > > >

June 3, 2019

OSProcess and CommandShell available on GitHub for Pharo users

by David T. Lewis

Alistair Grant and I, with the support of Feenk, have made GitHub repositories for OSProcess and CommandShell at: https://github.com/dtlewis290/OSProcess-Tonel https://github.com/dtlewis290/CommandShell-Tonel Alistair did the conversions using Peter Uhn??k's migration tool, and I set up the repositories so that they can now be loading in Pharo as follows: Metacello new repository: 'github://dtlewis290/OSProcess-Tonel/src'; baseline: 'OSProcess'; load. Metacello new repository: 'github://dtlewis290/CommandShell-Tonel/src'; baseline: 'CommandShell'; load. Note, the two respositories are named *-Tonel because I also maintain a GitHub repository for OSProcess on Cuis, and will probably do repositories in Squot format in the future. @Thierry Goubier - If you have an account on GitHub I will add you as a collaborator (but my own development work remains on squeaksource so I prefer contributions there anyway). Enjoy, Dave and Alistair

June 3, 2019