December 2018 - Pharo-users

Re: [Pharo-users] how to use indexes to copy a substring out of a string

by Ben Coman

On Sun, 30 Dec 2018 at 17:53, Roelof Wobben via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > Op 30-12-2018 om 02:14 schreef Ben Coman: > > 'abcdefg' asArray overlappingPairsRemainderCollect: [ :a :b :rem | { > a.b.rem } ] > > This was deliberately only half a solution. The block above "[ :a :b :rem | { a.b.rem } ]" is a placeholder only - to show you what data you would have to work with. You need to adapt it. > Sorry, I do not see how this can work so I can find the answer > > qjhvhtzxzqqjkmpb is nice because is has a pair that appears twice (qj) > > so if I try it on the code for overlappingPairsRemainderCollect I see > this as answer : > > "#($q $j #($h $v $h $t $z $x $z $q $q $j $k $m $p $b))" > The line above looks pertinent!! Inside the block you will have... a ==> $q b ==> $j rem ==> #($h $v $h $t $z $x $z $q $q $j $k $m $p $b) <snip> > "#($p $b #())" > > How does help me the output in telling me that there are two pairs that > are there two times > You might start with the following block... [ :a :b :rem | self halt. rem overlappingPairsCollect: [ :a2 :b2 | ...something... ] ] and from in the debugger experiment by inspecting the second half of it. cheers -ben

Dec. 30, 2018

Re: [Pharo-users] how to use indexes to copy a substring out of a string

by Roelof Wobben

Dec. 30, 2018

Re: [Pharo-users] how to use indexes to copy a substring out of a string

by Roelof Wobben

Dec. 30, 2018

dÃ©sabonnement

by bruno barske

Dec. 30, 2018

Re: [Pharo-users] how to use indexes to copy a substring out of a string

by Ben Coman

On Sun, 30 Dec 2018 at 00:29, Roelof Wobben <r.wobben(a)home.nl> wrote: > Hello, > > Still working on AdventOfCode > > I'm struggling to see how this can be solved. > > Now, a nice string is one with all of the following properties: > > - It contains a pair of any two letters that appears at least twice in > the string without overlapping, like xyxy (xy) or aabcdefgaa (aa), but > not like aaa (aa, but it overlaps). > > To exclude overlaps, one approach could be to subtract each candidate pair from the string and then check the remainder-string for matches. I'm not sure, but suspect that as the candidate pair progresses through the string, only the trailing remainder-string needs matching since the preceding remainder-string has already been checked. So a Pharo 7 Spotter search for 'pairs' finds 28 implementors where SequenceableCollection>>overlappingPairsCollect: looks quite close to what is required... 'abcdefg' asArray overlappingPairsCollect: [ :a :b | { a.b } ]. "#( #($a $b) #($b $c) #($c $d) #($d $e) #($e $f) #($f $g))" Reviewing its implementation... SequenceableCollection>>overlappingPairsCollect: aBlock | retval | retval := self species ofSize: self size - 1. 1 to: self size - 1 do: [:i | retval at: i put: (aBlock value: (self at: i) value: (self at: i + 1)) ]. ^retval it can be adapted to provide also a remainder... SequenceableCollection>>overlappingPairsRemainderCollect: aBlock | retval | retval := self species ofSize: self size - 1. 1 to: self size - 1 do: [:i | retval at: i put: (aBlock value: (self at: i) value: (self at: i + 1) value: (self allButFirst: i + 1)) ]. ^retval for use like this... 'abcdefg' asArray overlappingPairsRemainderCollect: [ :a :b :rem | { a.b.rem } ] "#( #($a $b #($c $d $e $f $g)) #($b $c #($d $e $f $g)) #($c $d #($e $f $g)) #($d $e #($f $g)) #($e $f #($g)) #($f $g #()))" > - It contains at least one letter which repeats with exactly one > letter between them, like xyx, abcdefeghi (efe), or even aaa. > > You might adapt "overlappingPairsCollect: aBlock" into "overlappingPairsSkip: n collect: aBlock" but changing "size -1" and "i + 1" into "size - n" and "i + n" HTH cheers -ben P.S. If #overlappingPairsSkip:collect: seemed generically useful to push into Pharo, then the following would be redefined to reuse it... SequenceableCollection>>overlappingPairsCollect: aBlock ^self overlappingPairsSkip: 1 collect: aBlock The extra layer of function call doesn't add much overhead. On the other hand #overlappingPairsRemainderCollect: does lots of extra copying through #allButFirst: so would not be so good for reuse by #overlappingPairsCollect:

Dec. 30, 2018

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

Hi, Thanks for the link. For some strange reason, I do not see the linked email in my inbox. I am happy to hear that you could install GT. > * The new interfaces and some demo of the graphical elements look > pretty good > * After just some operations including window resizing I just get the > Red Window of Death [1](https://i.imgur.com/Cbx7uyH.png). Indeed, that is a known problem: https://github.com/feenkcom/gtoolkit/issues/64 > * I like the little triangles to expand thing in the document and the > run buttons for embedded code, and the "embeddability" of elements > in the document in a tree like fashion, which of course could lead > to documents that embed pieces of documents, which embed pieces of > documentsâ¦ But the dual panel view of code in one side with > results in the right panel of old GT didn't tend to create such > "recursion". This dual modal view is the same of > Atom[2](https://is.gd/kegaso) and CodiMD[3](https://is.gd/wudugi) > for interactive documentation and I would like to see examples more > in that line... but I don't know how it suits the philosophy behind > Documenter, which seems more aligned to a modal non dual view of the > document where you enter into edit mode once you click a piece of > the document and into a view mode once you are out of it (instead of > the proposed dual view). Would be nice to see is such dual view can > be used to directly operate on the rendered view and see changes in > the markup (i.e resizing an image in the rendered view changes the > value on the edit view). Interesting observation. The linked tools as all other notebook technologies I saw rely on two distinct modes for edit and view that reside in two distinct widgets (editor and viewer). They do that because they simply cannot have it in one. Because of the design of Bloc we are not constrained to that. Instead, we build a seamless interface that is both optimized for viewing, and for editing with live preview that does not rely on an explicit render button. This approach enables direct manipulation without friction, and we think this is a significant advancement in this space. About the remark related "to documents that embed pieces of documents, which embed pieces of documentsâ: It is indeed possible to embed documents in documents, but I am not sure I understand where you see the issue appearing. Could you detail this part? > * I like the different view that a document can have, markup wise: > Pillar, Markdown, LaTeX, HTML, DeckJS AsciiDoc as is demoed in the > authoring part [4](https://i.imgur.com/Jc1T5Rm.png). Interestingly, those extensions exist in the old Inspector as well. > * Its difficult to travel between the panels of a playground. > Previously you just make click in the lower circle representing the > panel you want to go at it was done > [5](https://i.imgur.com/4CDAM2o.png), but now clicking on the upper > rectangle representing such panel has no effect > [6](https://i.imgur.com/8Obo3Ct.png). For now, you have to rely on horizontal scrolling using a trackpad or mouse. Alternatively, Shift+scroll should also work. The upper part is not yet ready. > * Auto-completion and shortcuts for selecting text doesn't work well > on code cells of the new playground. Selecting whole words with Ctrl > arrow doesn't work, neither using down arrows to choose from > suggestions and even you can end with previous suggestions floating > around your playground [7](https://i.imgur.com/4awyIft.png) > [8](https://i.imgur.com/7qXc64b.png). Indeed. These are known issues that we will tackle soon. > * The default data science example didn't work at all > [8](https://i.imgur.com/YhNb8el.png) Nice catch. Thanks. The path of the file is incorrect when the image is copied. >> Now, a clarification. The old GT was produced over a period of 4 years >> by an open-source team. The project had its own identity, and in 2014 >> the core of it was first integrated in Pharo. I say the core of it, >> because the visual part and other libraries are not in Pharo today. >> >> The full potential is found in Moose. In any case, during this >> process, GT got to be identified with Pharo and that was a good thing. >> The new GT is a product produced by feenk, a company. Much of the >> original team is still active in the new version, but now we commit to >> our product in a different way. The product is free and open-source, >> but itâs still a product with an identity and a goal. At present time, >> both the team, identity and goal are different than those of Pharo. >> >> Our goal is to offer a fundamentally new alternative to program >> (including comparing to what is possible now in Pharo). We are not >> looking for marginal improvements, and we are not aiming at backward >> compatibility. > I used Moose to build the first Grafoscopio versions, but there was a > lot of stuff that was related with software analysis that I didn't > really need for reproducible interactive documentation and publishing > nor for data science, activism and storytelling. So once old GT was > integrated into Pharo with Spec I used a more minimal setup to deliver a > more focused experience. > > I think that most times this relationship between Pharo and Moose can be > of creative tension, one pushing the boundaries and the other offering a > more stable experience where the innovations of the former are > integrated and debugged. But even after using Moose as a fully > integrated vision of what old GT have to offer in the back and front > end, I didn't see any migration path from previous Moose with the old GT > to the current GT, which is kind of worrisome. I understand the idea of > forks in FLOSS as a way of dealing with politics behind the FLOSS > movement and the relationship between different visions and actors > (individuals, communities, enterprises, foundations, associations and so > on). It has happened before with Squeak, Pharo and Cuis and I'm fine > with that. And I understand that a healthy relationship with the past > means sometimes to break with it and jump into the future. > > That's why I think that the role of for profit and non for profit > institutions is to balance a sense of momentum and stability around > FLOSS. I would like to see a more clear road map for GT, knowing ahead > where backward compatibility will be broken and why, which are the > visions and, more importantly, how to participate and where are the > boundaries. These are difficult tasks, but if the participation and > boundaries are explored collectively, you can also know about the first > ones (visions, versions, forks, compatibility). In that sense I think > that Pharo is putting a good example: we have a clear road map document > and participation process in the public repositories, there are public > channels for users and developers and the private companies know about > them, so they can put the boundaries about what is going to be done in > the open, with the community, and what is to be kept closed inside > company's frontiers and channels and the company's own velocity. I don't > know if Feenk is planing something similar for its new vision, product > and identity, and I don't know if the new alternative will have its own > non-profit organizations as a neutral entity for all players using GT, > but would be good to know about that, not because there are not people > willing to jump into the future, but we would like to know to which > future we're jumping on. Without that I think that is a safer bet for > myself to rely on Pharo and see how migration paths could ensure > compatibility with my own past and the one of my local community using > Pharo and GT based tools. I hope that the open source nature of both > products (Pharo and new GT) will ease the cross-pollination of the more > interesting ideas, even without sharing code, visions or UI. We do not regard our work as an evolution, and we are not concerned with backwards compatibility. We are not trying to be completely different to what we had before, but being compatible is simply not a goal. For example, extending oldInspector is usually a matter of a dozen lines. Extending the new Inspector works in a similar way, but with a slightly different API that is needed because of the new infrastructure. The migration is not a pain, and it can happen seamlessly as I described in the mail to Luke. I understand how from your point of view as a user of Pharo and oldGT you regard backward compatibility as important. However, we look at things differently. We think that development can be enhanced both from an efficiency and from a happiness point of view with a significant degree. When something like this is possible, the opportunities are different, too. For example, backward compatibility is about limiting costs. However, when the profit promise can be large, some costs can be worthwhile and are to be considered investments. What do we mean by profit? For example, what would it be worth for a company to have the non-technical people literally pair and understand the internal details of the domain model? Compared to what exists now, that can be invaluable and we think that following moldable development this will be a natural by product. Another example: what would it worth for a developer of a library to build a live documentation with a marginal effort that simply leverages the testing effort? It can be invaluable, and we think this is trivially possible. About the roadmap, here it is: we aim to build a complete development environment that will enable moldable development. We understand how this can appear vague. I think itâs not because I and my colleagues talk about it since many years now. People pay little attention, so now we set ourselves to deliver a concrete incarnation of what we think the future should look like. We set to create something that does not exist in other parts, and we simply do not quite know how this will look like in details. For example, we do know that we want to build a Coder or a Debugger, we even have advanced ideas and implementations, but we do not know exactly how it will look like and because of that we also do not quite know how long it will take. We have a particular way of approaching development that relies on fast feedback and storytelling, and at the end we always get surprised of where the journey takes us. For example, the current state of Documenter was simply difficult to imagine even 4 months ago, and in the process we threw away more code than is now released. So, we will not detail the concrete steps because we do not work like that. We do have a clear vision of what we think software development should be, and we will put forward our guiding principles shortly. About the governance process: GT is built by feenk and will continue to be so for the foreseeable future. We put things that we create in the open, we do so for free, and we welcome people to engage with us. >> To build this alternative we invested in a whole new stack. That is >> not a tiny challenge and getting it right requires many iterations and >> feedback. We say we are in alpha not because of inconveniences of >> installation but because we are still very much developing the product. >> >> We announced the first alpha version in September and since then much >> has changed. At present time, we did manage to reach a situation where >> downloading the distribution should run on Mac, Linux and Windows. >> Even so, the current version is only for people that do want to try >> knowing that there will be hurdles. > > I think that not only installation inconveniences is related alpha, but > also this jumping from old GT to new one without a clear migration path > (as is expected from alpha software and processes). I'm fine with that > too, but I think that once the new GT reaches beta status the backward > compatibility should be more important and meanwhile the non regard of > that should be stated more promptly for previous and future GT users. I > imagine that, at some point Feenk will provide its users and customers > with clear support and migration paths regarding its open source > products (kind of what happens with Canonical and the Long Term Support > versions of Ubuntu). As mentioned above, our focus is to build a new experience. It is likely that a typical Pharo user will not have much issues adapting to the new interface. A developer that depended on the old APIs will be somewhat impacted, but we do not expect a too large effort will be required to adopt the new world. Nevertheless, if itâs stability and predictability you are looking for, it is best to wait for now. >> A word about the user experience. The current version runs inside the >> Pharo UI because we need to bootstrap. But, our goal is to build a >> complete IDE on the new stack. If you want to judge the user >> experience, it is only meaningful to do it within the GT windows, and >> not by comparing it with the rest of the existing Pharo UI. >> >> Does this clarify the situation? > Yes, it does. It seems that a fork is coming, at least UI wise regarding > Pharo and new GT, but if the community knows about it, I'm fine with > that. I think this thread also clarifies what active users of old GT > will expect from upcoming versions of new (non alpha) GT regarding > compatibility, open processes, visions and so on. Hopefully we will > reach that place together. I do not think a new piece of code should be called a fork. At this point in time, GT and everything it comes with, loads cleanly in Pharo 7. Cheers, Doru > On Dec 29, 2018, at 5:10 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi Doru, > > This one is still pending: > > https://www.list.inf.unibe.ch/pipermail/moose-dev/2018-December/027542.html > > Of course we have slow days at end of year and I don't expect immediate > answer, but now that discussion was active is good to point some pending > conversation, even to be taken after holidays. > > Cheers, > > Offray > > On 29/12/18 6:38, Tudor Girba wrote: >> Hi Offray, >> >> I believe I replied to all your emails. If I missed one, please point me to it. >> >> Cheers, >> Doru >> >> >>> On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>> >>> >>> On 28/12/18 8:03, Tudor Girba wrote: >>>>> On Dec 28, 2018, at 1:08 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: >>>>> >>>>> WOW >>>> :) >>>> >>>> What part of it do you like? >>>> >>>> Cheers, >>>> Doru >>> And which parts you don't? >>> >>> I wrote a long mail regarding good and no so good parts of the new GT >>> experience, including features possible forks, that I hope will be >>> answered also in detail, to keep the big picture. >>> >>> Cheers, >>> >>> Offray >>> >>> >>> >> -- >> www.feenk.com >> >> "You can inspect and adapt only what is explicit." >> >> -- www.feenk.com "No matter how many recipes we know, we still value a chef."

Dec. 29, 2018

Re: [Pharo-users] how to use indexes to copy a substring out of a string

by Roelof Wobben

Op 29-12-2018 om 21:05 schreef HernÃ¡n Morales Durand via Pharo-users: Thanks, I will look at these but I think there are too advanced for Aoc challenges but maybe I see a way to solve it more easily

Dec. 29, 2018

Re: [Pharo-users] how to use indexes to copy a substring out of a string

by HernÃ¡n Morales Durand

Hi Roelof You may have a look at my StringExtensions package at https://github.com/hernanmd/StringExtensions I wrote several algorithms for working with substrings like: https://github.com/hernanmd/StringExtensions/blob/master/repository/StringE… https://github.com/hernanmd/StringExtensions/blob/master/repository/StringE… Some of them used in https://github.com/hernanmd/BioSmalltalk where you can find also algorithms for k-mer counting and clump finding: https://github.com/hernanmd/BioSmalltalk/blob/master/repository/BioTools.pa… https://github.com/hernanmd/BioSmalltalk/blob/master/repository/BioTools.pa… for the Bio repo just consider a Sequence like a more advanced String. Cheers, HernÃ¡n El sÃ¡b., 29 dic. 2018 a las 13:29, Roelof Wobben (<r.wobben(a)home.nl>) escribiÃ³: > > Hello, > > Still working on AdventOfCode > > Im struggeling to see how this can be solved. > > Now, a nice string is one with all of the following properties: > > It contains a pair of any two letters that appears at least twice in the string without overlapping, like xyxy (xy) or aabcdefgaa (aa), but not like aaa (aa, but it overlaps). > It contains at least one letter which repeats with exactly one letter between them, like xyx, abcdefeghi (efe), or even aaa. > > my game plan was this > > 1) group the characters and filter everything out which has a count not equal to two > > 2) find the indexes of the characters and with the indexes use a copy method so I have a substring out of it > > 3) do the same with the substring so again 1 and 2 > > but how can I make 2 work. > > Roelof > >

Dec. 29, 2018

Re: [Pharo-users] Subscribing to streaming input with ZnClient

by Sven Van Caekenberghe

Very nice, and thank you for the feedback. > On 28 Dec 2018, at 23:16, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > On 12/27/18 9:00 AM, Sven Van Caekenberghe wrote: >> Hi Jimmie, >> >>> On 27 Dec 2018, at 15:15, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >>> >>> Hello, >>> >>> I am wanting to subscribe to a perpetual stream of JSON data in my app. I have failed to find an example which helps me understand how to do so. It may be there but I have not discovered it. >>> >>> How do I do something like that? A curl example from the website. >>> >>> curl \ >>> -H "Authorization: abcdefg?????" \ >>> "https://stream-mystreamingsite.com/stream?query=whatIwant" >>> Response Headers >>> HTTP/1.1 200 OK >>> Access-Control-Allow-Headers: Authorization, Content-Type, Accept-Datetime-Format >>> Access-Control-Allow-Methods: PUT, PATCH, POST, GET, OPTIONS, DELETE >>> Access-Control-Allow-Origin: * >>> Content-Type: application/octet-stream >>> >>> >>> After subscribing to the stream I will need to get and access the JSON data so that my app can process it. >>> >>> Any help and wisdom greatly appreciated. >>> >>> Thanks. >>> >>> Jimmie >> The client and server part of the WebSockets extension to Zinc HTTP Components already supports similar functionality, so this is certainly doable. >> >> Unless you can give me a public end point to test, I can only write some untested pseudo code. >> >> | client reader | >> client := ZnClient new. >> client url: 'https://stream-mystreamingsite.com/stream?query=whatIwant'. >> client streaming: true. >> client headerAt: 'Authorization' put: 'xxx'. >> client get. >> reader := NeoJSONReader on: (ZnCharacterReadStream on: client contents). >> [ reader atEnd] whileFalse: [ reader next ]. >> reader close. >> client close. >> >> Be sure to tell us how you got it working. >> >> HTH, >> >> Sven > > Hello Sven, > > Thanks for your help. > > The server I am connecting to requires an account to access. But you provided sufficient information to get me going. Thanks. > > This is for a Trading Application. I am a ways off before ready for releasing. I will open source when it is usable and cleaned up enough from personal code. > > Currently I have named it SmallTrader, hence the ST prefix for classes. > > I have an STClient class which subclasses ZnClient and sets it up with the necessary account authorization. > > Below is the STPriceStream#mainLoop method. > > Basically it is populating some OrderedCollections in the STPriceStream which are available to the app's mainLoop. > > It is working perfectly. I currently have it printing out data to stdout so that I can watch the data it collects to visually understand what is happening. > > The connection below is the instance of the class which connects to this specific broker. Since connections are specific to a broker I am putting all of the parsing into ST objects such as STPrice and STCandle in the broker specific class as it understands what the broker returns. This will allow my app to be able to use different brokers simply by changing which connection class we call. Currently I am writing for one specific one where my account is located. But I want to be able to add brokers in time. > > Thanks again for your help. > > mainLoop > | delay pricesStream reader | > delay := (Duration milliSeconds: 100) asDelay. > minuteDateTime := STCandle datetimeMinute: (DateAndTime now asUTC). > pricesStream := connection newPriceStreamConnectionForInstruments: instruments. > pricesStream get. > reader := STONReader on: (ZnCharacterReadStream on: pricesStream contents). > [ reader atEnd] whileFalse: [ > stop > ifFalse: [ | price | > price := connection pricesStreamNextPrice: (reader next). > price ifNotNil: [ > prices add: price. > price datetimeMinute = minuteDateTime > ifTrue: [ minutePrices add: price ] > ifFalse: [ self processMinutePrices: price ]]] > ifTrue: [ > reader close > ^ self ]. > delay wait ]. > > > Jimmie

Dec. 29, 2018

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Offray Vladimir Luna CÃ¡rdenas

On 23/12/18 3:21, Gour wrote: > On Sat, 22 Dec 2018 12:53:16 -0500 > Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: > >> I don't know yet, but I would like to use Tonel and some import/export >> tools to use Fossil as my backend for file based storage instead of >> Git. > I can fully understand you - using Fossil is so easy and safe in comparison > with Git where one never knows... Yes. I think that DVCS wise, developers imagination has been monopolized by Git/GitHub. There are powerful simple little tools out there that are practically outside of the developers' radar. Let's see what happens in the Fossil + Pharo integration front. >> These days are particularly slow in Colombia, but I will post advances >> as soon as I have something. > Thank you. > > Btw, I looked at Grafoscopio and it is interesting you had been looking > or using tools like Leo editor, Pollen - I also considered Skribilo > (Guile) - since I am also searching some toolchain to improve web > publishing (paper output is not problem with LateX or ConTeXt) , but > still haven't decided what to use/learn since learning Racket/Pharo > requires some extra time until it can pay off (I want to stay focused > on my writing and studying and not turn myself into programmer)...for > now I'm still using Emacs/markdown-mode although in the past I spent > time with both AÑciidoc(tor) and rst markups. I looked also at Skribilo in my search for more powerful tools for interactive writing and documentation, and Emacs/OrgMode (see [1]). I really liked the Racket approach of a meta programming tool for making Domain Specific Languages (like the ones used for documentation). But in the development front I think that Pharo/Smalltalk is hardly beaten by anything, more if you're thinking not only in publishing (web, mobile or print) but also in agile data visualization (see [2]). In that regard becoming a coder was a valuable deviation from my research and study that paid huge reward later in those fronts also. [1] https://duckduckgo.com/?q=devops+org+mode&atb=v76-7&iar=videos&iax=videos&i… [2] https://vimeo.com/94724841 Is good to see more interest in interactive documentation in this community. It seems that good times are coming. Cheers, Offray

Dec. 29, 2018