Self-interest June 2016

self-interest@lists.selflanguage.org

19 participants
15 discussions

Improvement proposals
by Bystroushaak 21 Jun '16

21 Jun '16

[Repost of the https://blog.selflanguage.org/2016/06/18/improvement-proposals/] I would like to spur discussion about structure of the project and also about the community, its organization and knowledge bases. I believe that this discussion is really important for the future of Self development. Self is open source, which is important, but not sufficient condition to thrive. Open source success is only partially given by the license, but more importantly by the community of people around projects. In the end, it is the people what makes all the difference. Self has somehow sleeping community, which I think is partially because we don’t have good tools for communication and self-organization. Here is what I think that would be useful: Official Github organization Github allows to create „organizations“, which is used to group multiple projects under one „official“ entity. Current state of Self on Github is confusing, especially for newcomers. From what I understand, „official“ repository is the one in Russel Allen’s personal account, but there is no „THIS IS OFFICIAL REPOSITORY, CONTRIBUTE HERE“ sign. People have to figure this on their own and hope that they didn’t figure it wrong. I would also recommend to split the Self repository into several smaller, single-purpose-oriented repositories. For example: separate the handbook, and maybe application directory (git can do this <http://gbayer.com/development/moving-files-from-one-git-repository-to-anoth…> without the loss of history). It would be probably good idea to decide if we want to allow anyone to access this „organization“ and to let anyone add their own application repositories. This would simplify the discovery of available Self software. Other possibility is to use it only for „official“ stuff and „syndicate“ Self packages somewhere else (wiki or package repository). Talking to the people We need to start to talk to the people. This is a problem that all smaller projects have; there is too much context in your head (this is relevant to the /bus factor/ from previous blog <https://blog.selflanguage.org/2016/06/15/lessons-learnt-from-the-self-archi…>). The „THIS IS OFFICIAL REPOSITORY, CONTRIBUTE HERE“ sign is the classical example of the context that everyone from the mail-list have. It was posted few times into Self conference, but for anyone coming outside the Self community, this is really hard to figure. You have to talk to people, or they won’t know. The Self wiki <https://github.com/russellallen/self/wiki> is another example of this problem. There is no sign that there actually is a wiki. I suggest to put a BIG animation with dancing whores ladies with „HELLO FRIENDS, YOU ARE WELCOME HERE AND WE WANT YOUR CONTRIBUTION“ sign in their hands to the README and to the homepage. If you want something from the people (eg. contribution), you have to tell them. They are not mindreaders and they won’t engage without knowing that it is ok to engage. For example, I pushed a lot of typo and RST formatting fixes to the Self Handbook / Russel Allen’s git repository and I felt really uneasy doing this. Is it okay to contribute? Is it okay to make changes in someone else’s work? Community WIKI 15.12.2010, 09:55 Thorsten Dittmar written: hello folks, for me self is still one of the most beautiful languages I know, but the lib's are not so shapelily. So we have a kind of an Ugly Duckling here... a lady with amazing intrinsic values and horrible "lips"... Of course, we can start with some cosmetics.. We can change the UI and other stuff, but for me that doesn't look like the right way... Self has so many unfinished stuff, that I guess we will not make it better to open another bottle. What is /„unfinished stuff“/? What is the state of Self? Where is the FAQ? Where is the screenshot section? Where is community knowledge base? Where is documentation? Where is the detailed description of VM? Where do you collect information? Currently, only way to get a clear idea about Self and its state is to read the mail archive <https://blog.selflanguage.org/2016/06/09/self-mail-conference-in-mbox/> and the 115 thousands lines of C++ sources. Mail archive is the worst possible database for this kind of stuff. Not only that history is not easily accessible for newcomers, it also cannot be edited and improved. Also attachments don’t work much. We need good community Wiki, where we can: * collect information about Self * document the VM * document aspects of programming in Self o It is really hard to find any source code to study. There are applications in Self’s git repository, but it took me 6 months to notice. Again, there is no signs pointing to this. * discuss various stuff about Self, ideas, improvements, highlights and so on * document what is in bad shape, what needs to be done and plan future work * provide user’s sections o Something like a blog, but for all kinds of data, files, snippets and information related to Self, that user’s may save for benefit of themselves and others. o This need to be under user’s control. * have user profiles – some small section, where you may shortly introduce yourself and maybe tell others what you do o It is hard to tell who is working on the Self and what are they doing. Again – this is context information which are not available. * collect list of links to all relevant Self information sources o I am willing to do this and maintain this section. * collect list of links to Self alternative interpreters and inspired languages o I partially did this in previous blog. * tell people how to contribute, where to contribute and other community information o Viz „Talking to the people“. Wiki is important part of the plan to increase the Self’s bus factor (see previous blog). It also helps people (newcomers especially) to put themselves into perspective of what Self is, how to interact with community and how to contribute. I am willing to be maintainer of this Wiki. I don’t really want to, but I have strong feeling, that if I am not going to do it, nobody will. Github wiki I don’t think it is a good idea to use this specific wiki software, because to me, it looks like it is seriously limited in capabilities. I like, that it uses the Git for synchronization, but I feel, that we will need something more advanced. Something that will be able to host large variety of content, categories and discussions. When I think about it, I see it like the hybrid between the c2 wiki <http://c2.com/cgi/wiki/FrontPage> and Wikipedia. I don’t expect anyone to come with clear solutions, but I think that we need to talk about this and look at alternatives. What do you think? Package repository One of the services, which I think is critical for success of any language is the package repository and package manager. I am not that sure how easily this may be done for Self, but I am 100% sure, that this is necessary for larger adoption; We need to give people the tool, which will allow them to build applications on top of other people libraries. Not just that – also the place where we can discover new libraries and projects, instead of having them scattered all over the Internet. I have a lot of experiences with Python and believe me when I say, that this is big win for the language and big reason to use it. Community decision I know, that Self was a research language, and partially probably still is. I will impersonate the Generic Beginner* and speak using his voice, when I say: I think that after 26 years, it is time to make up your mind. How do you perceive Self? What is it to you? Do you take Self seriously, or is this just a game? I can’t build a product on Self in its current state. I can’t afford to wait decades for improvements. I need to know, whether I can count on you (the community). I may put my time and/or resources into Self, but I need to know that I won’t be wasting my time, and that I am not alone. I want to know your opinion. It may be clear in your head, but again – if you don’t talk to the people, they won’t know. For me, this is NOT a game. What about you? *Not necessarily my opinion, but I think it comes to mind of all newcomers looking at Self and thinking „hey, this looks nice, should I use it?“

10 33

Alan Kay AMA
by Bystroushaak 21 Jun '16

21 Jun '16

Alan Kay is doing AMA (Ask Me Anything) on the Hacker news: - https://news.ycombinator.com/item?id=11939851 Here is my question related to Self: - https://news.ycombinator.com/item?id=11941330

4 3

Re: [self-interest] Improvement proposals
by Derrell Piper 19 Jun '16

19 Jun '16

I agree. That's inappropriate. ddp(a)electric-loft.org • roving

1 0

Lessons learnt from the Self archive
by Bystroushaak 16 Jun '16

16 Jun '16

[Repost of the https://blog.selflanguage.org/2016/06/15/lessons-learnt-from-the-self-archi…] I’ve spent 26 days reading 26 years of messages from the Self mail conference archive </2016/06/09/self-mail-conference-in-mbox/>. Here is what I’ve learned. Please note, that everything is highly subjective and may be even wrong. Interesting messages If you don’t want to go through all 4334 messages of whole archive, you may read just this dataset, which contains only 295 messages I’ve found interesting enough to save into separate directory. I’ve saved each message because it answered some of the questions I had, or because it was marking important milestone in Self development. * https://github.com/Bystroushaak/self_mbox/raw/master/datasets/self-interest… List of alternative languages / interpreters When I’ve got to year 2004, I’ve realized it may be valuable also to store list of alternative interpreters and languages, which were sent to the conference, so I’ve began to collect them too. When I finished the reading, I’ve spent an hour by scanning the 1990-2004 timeframe, but I’ve maybe skipped something. * https://github.com/Bystroushaak/self_mbox/raw/master/datasets/self-alts.mbo… Just to give you the idea, here is the reduced list of topics (there is more in the archive): * tinySelf progress report * JSelf Home Page * Announcing OpenSelf * A Self _ BETA Language Hybrid Project * premature announcement: SELFISH * Brain language * SELF for VisualWorks 5i * dSelf * New release of Cel * Self_R not started yet * Io * Zero, a programming system * [ANN] Slate 0.3 Released! * Re: Self for Squeak * Klein open-source release * Self-style outliners for Javascript * Phos * Anyone have a copy of Kevo? * Re: Distributed Objects * Re: UnitTests * AmbientTalk * Self in Javascript progress * Re: Self in Javascript progress * Re: goals (was: dynamic deoptimization) * Pooi: A prototypical object-oriented interpreter * Avacado: JavaScript trying to be more like Self * BOS1.2 release — play it again, sam * Smalltalk interpreter of Self Everything is dead, or dying Self is small project maintained, discussed and used by only handful of people over two and half decades (one generation). It is slow game, and changes may take years (new releases), or decades (porting to new systems). This leads to massive link rot <https://en.wikipedia.org/wiki/Link_rot>. It may not be evident if you are just participating from time to time, but when you look into archive, it is a clear trend. Only a few people were able to keep attention and interest over the decades and maintain resources they created. There were a lot of those who lost interest or just didn’t have the time and their resources are dead. Beginning of the Self conference archive is in 1990, which was a few years before the HTML and HTTP was invented. I have no idea, how people organized work and thoughts in groups at that time (text files via FTP maybe? telephone and paper notepads?), but it is either converted to a few existing HTML resources, or (most likely) dead. You won’t see the design decisions, discussions or thoughts from that time. Then HTML and HTTP came. People were excited about this new protocol: From urs(a)cs.stanford.edu Sat, 19 Mar 1994 11:53:23 PST: Thanks mostly to Bay-Wie Chang, Self now has a Mosaic home page, http://self.stanford.edu All of our material continues to be available via ftp, but the Mosaic interface is definitively friendlier (e.g., it has an online bibliography and paper abstracts). Enjoy! -Urs It was definitely an improvement. But idea to create articles and webpages about Self and put them on your web lead to massive resource fragmentation. I am not criticizing, merely pointing to a fact, that almost every link from that time is dead, because it was not maintained in long-term and that whole situation is actually unmaintainable by one person, even if that person really wanted to maintain it. That url in the email is by the way – dead <https://web.archive.org/web/*/http://self.stanford.edu>. When you think about it, almost every time anyone counted on third-party service, it didn’t pay off. From that point of view, everything is dying, we just don’t see it, because it still exists. But for the future newcomer to Self, it is already dead. If you think in the time-frame of decades, all providers of services will end, often without replacement. Look at geocities for example. Once it was hosting for hundreds of thousands of webs. Now it is dead. Sourceforge killed itself by adding adware to user’s packages, and Yahoo is slowly dying and it is only matter of time until someone will buy it and shut down most of its services for good, because it is not profitable. University pages are chapter for itself, because almost all of them are dead soon after the person who created them leaves the university. Even if the webarchive or other web cache archives the original, this is not the long time solution. There are various copyright attack in place right now, which may cause such services to close. This may not look like a big issue, but for newcomers, this means that half of the valuable resources is not available. If you look at what survives, it is almost always only files which were downloadable and thus shared by large number of people. In this sense, git is the best solution, because it allows everyone to clone the repository and synchronize it with others, even if the original resource is gone. There is two possible options on how to overcome this problem: * distributed standalone information resources shared by everyone * maintained centralized group resources If you create your own webpages, make them easily downloadable and sharable. Otherwise, they will be dead soon (5-20 years from now). Other option is to write articles in postscript / PDF and generally standalone files, which will be distributed to large number of people. Second option is to make central repository of knowledge consciously maintained and hosted over the years by Self community at one place. Preferably in the form of Wiki. I will get back to this later. Honorable mentions FTP that refused to die Date: Fri, 25 Aug 1995 12:45:08 +0200 From: rainer(a)physik3.gwdg.de (Rainer Blome) To: self-interest(a)self.sunlabs.com Subject: non-official ftp site in germany (solaris only) The link speed to Sun was really not acceptable when I tried it, so I was glad to be able to get Self from Manchester. Seems that I have been lucky now that the site is down. The FTP admin of our local computing centre was so kind as to put Self 4.0 on his server. It is not official and may vanish any time, but they have lots of disk space and I suppose it won't. Still, please don't use this site unless it is a lot faster than your link to the USA. Since the stuff is the one that I used to install Self here, it doesn't look exactly like the original (all files have the Self-4.0 prefix) and it is not complete (I only installed the solaris version). /ftp.gwdg.de:/pub/languages/self: total 12110 -rw-rw-r-- 1 emoenke 1475 Jul 26 17:05 Self-4.0.Install -rw-rw-r-- 1 emoenke 1933 Jul 26 17:04 Self-4.0.LICENSE -rw-rw-r-- 1 emoenke 1087 Jul 26 17:05 Self-4.0.README -rw-rw-r-- 1 emoenke 71809 Jul 26 17:05 Self-4.0.readThisFirst.ps -rw-rw-r-- 1 emoenke 12320062 Jul 26 14:16 Self-4.0.solaris.tar.gz Also, the tar file is gzipped instead of compressed. Not having patched the install script, it won't work anymore (unless you linked zcat to gzcat), but what Install actually did was just a single line anyway: gzip -cd Self-4.0.solaris.tar.gz | tar -xfpB - Greetings, Rainer The FTP is still there, but sadly the Self directory isn’t. merlintec Jecel Mattos de Assumpcao Jr <http://www.merlintec.com/lsi/jecel.html> is my new personal hero. Not only that http://www.merlintec.com/ still works and didn’t lose any of its contents, also his messages on various topics in the conference were really great and it was pleasure to read it. Self is really complex There is 114 821 cloc <https://github.com/AlDanial/cloc> lines of C++ code (counted without comments, blank lines and so on). There is two kind of compilers (NIC, SIC), assembler and other platform-dependent stuff. Almost none of it is documented outside the code itself. This is bad. Really bad. I did a little bit of C++ back in high school, but I can’t really imagine going through all this code and trying to make sense of it. It is extremely hard to get an idea what Self really is, what parts is it made from. Best thing documenting how Self works is this schema from the handbook: We need pictures like this that will document components of the VM. Schematic blueprints for what Self is and how it approximately works. Sometimes, pictures says more than a thousand words. If you don’t think that this is serious, here is a list of reasons: * It is hard for beginners to even get the idea what Self is. We know, that it is a language, but it is also virtual machine, bunch of compilers, memory managers and what not. It is almost like small operating system. * It is hard for anyone who wants to contribute to get an idea where to do the change. * It is hard for anyone who wants to port the Self to another architecture / OS. * It leads to fragmentation. People rather create own forks, or whole new languages rather than to try to make sense in so much C++ code. Linux An example of the complexity of Self was its porting to Linux. First message about porting to Linux was probably this: From dirkst(a)POOL.informatik.rwth-aachen.de Tue, 18 Aug 92 11:04:58 PDT From: dirkst(a)POOL.informatik.rwth-aachen.de (Dirk Steinberg) Date: Tue, 18 Aug 92 11:04:58 PDT Subject: Message-ID: <9208181757.AA24531(a)messua.informatik.rwth-aachen.de> MIME-Version: 1.0 Content-Type: text/plain Hi, I have recently read about Self and ftp'd some papers from self.stanford.edu, I even got the sun4 version of Self 2.0 and played around with it for a few minutes. Otherwise, I have no experience with Self whatsoever, but from what I read I am kand of enthusiastic. My question: Is anyone porting Self to some other platform, maybe even to the 386? I have Linux running on a 486/33 w/ 16 Meg RAM and 500 Meg HD, which should be a workable system for Self; I have gcc-2.2.2 and libg++-2.2, so it should be possible to compile the virtual machine (judging from the README's). BUT: I have the feeling that the compiler really generates native SPARC code and so one would have to write a completely new backend and assembler for the 386. I guess that would be a *major* project!?? Is the compiler/assembler written in Self or C++? If Self is tied to the SPARC achitecure and inherently non=portable, then that would nagatively influence the impact that this exciting software could have. How about using the gcc backend? Thanks for any info, Dirk Dirk Steinberg dirkst(a)pool.informatik.rwth-aachen.de This is from 1992. First (not fully ported) Self for Linux came in 1999, by /Gordon Cichon/, but that wasn’t really much usable, from what I’ve read. Proper support with GUI and everything working nicely took several more years. The bus factor is low As the wikipedia <https://en.wikipedia.org/wiki/Bus_factor> says: .. the bus factor is a measurement of the concentration of information in individual team members. It .. connotes the number of team members that can be unexpectedly lost from a project (“hit by a bus”, as it were) before the project collapses due to lack of knowledgeable or competent personnel. The bus factor of Self is incredibly low. From my own estimate based on reading the archive, I would say it is 5, maybe 7 if you want to be optimistic, probably 3 if you want to be pessimistic. This is not just bad, because it threatens existence of Self alone, but mostly because it also means that there is extremely low number of people, who /really/ understand Self, and almost no documentation, which can train new experts. Wikipedia offers following solution to increase the bus factor: Several ways to increase the bus factor (thus making the project more resilient) have been proposed: * Reduce complexity * Document all processes and keep that documentation up-to-date * Encourage cross-training. I don’t think, that there is much space for reducing the complexity, but second and third point may be solvable by community Wiki. YWAM KnowledgeBase <http://www.ywamkb.net/kb/Bus-Factor_-_Avoid_to_depend_on_a_single_person> also mentions two more interesting points: * maintaining documentation about how the corresponding website is working * forum for learning from each other Again, both points may be solved by community Wiki. Especially the second point is really important. Collected resources I’ve collected following links, which are not yet dead, or were archived by webarchive. I didn’t yet have time to go over them, so I am sharing them as I added them to my todolist: 1. http://kleinvm.sourceforge.net/ 2. https://github.com/aausch/klein 3. http://adamspitz.github.io/Avocado/ 4. https://github.com/jmoenig/morphic.js 5. http://lively-kernel.org/ 6. http://web.media.mit.edu/~lieber/Lieberary/Softviz/CACM-Debugging/Kansas/Ka… <http://web.media.mit.edu/%7Elieber/Lieberary/Softviz/CACM-Debugging/Kansas/…> 7. http://www.self-support.com/ 8. http://www.princeton.edu/~achaney/tmve/wiki100k/docs/Self_(programming_lang… <http://www.princeton.edu/%7Eachaney/tmve/wiki100k/docs/Self_%28programming_…> 9. https://web.archive.org/web/20010813120828/http://www.mri.mq.edu.au/~kjx/tg… <https://web.archive.org/web/20010813120828/http://www.mri.mq.edu.au/%7Ekjx/…> 10. http://merlintec.com/swiki/Self/2.html 11. http://merlintec.com/old-self-interest/threads.html 12. https://web.archive.org/web/20050121084338/http://www.lsi.usp.br/~jecel/mer… <https://web.archive.org/web/20050121084338/http://www.lsi.usp.br/%7Ejecel/m…> 13. http://www.merlintec.com/lsi/merlin.html 14. https://web.archive.org/web/19980123025609/http://www.cs.unm.edu/pad++/begi… 15. https://web.archive.org/web/20040607063757/http://linus.socs.uts.edu.au/~co… <https://web.archive.org/web/20040607063757/http://linus.socs.uts.edu.au/%7E…> 16. https://web.archive.org/web/20080307022735/http://www.consultar.com/JSelf/ 17. This file, when read into the initial Self system (empty world) creates just the objects needed to run a simple program that prints a table of factorials up to 49! and then stops. https://web.archive.org/web/20040312232625/http://www.lsi.usp.br/~jecel/rel… <https://web.archive.org/web/20040312232625/http://www.lsi.usp.br/%7Ejecel/r…> 18. https://web.archive.org/web/19991006225113/http://www.consultar.com/JSelf/L… 19. https://web.archive.org/web/20001109105100/http://www.consultar.com/JSelf/ 20. http://www.linuxsupportline.com/~openself/ <http://www.linuxsupportline.com/%7Eopenself/> 21. https://web.archive.org/web/20010405022406/http://openself.seul.org/ 22. https://web.archive.org/web/20070221212847/http://www.lsi.usp.br/~jecel/tut… <https://web.archive.org/web/20070221212847/http://www.lsi.usp.br/%7Ejecel/t…> 23. https://web.archive.org/web/20000815211509/http://www.research.microsoft.co… 24. https://web.archive.org/web/20080225110457/http://www.lsi.usp.br/~jecel/per… <https://web.archive.org/web/20080225110457/http://www.lsi.usp.br/%7Ejecel/p…> 25. https://web.archive.org/web/20000615190052/http://www.squeak.org/oopsla99_v… 26. https://web.archive.org/web/20000817004328/http://www.squeak.org/oopsla99_v… 27. http://www.merlintec.com/selfvmdoc/ 28. https://sourceforge.net/projects/selfish/ 29. http://www.3plus4.de/self/ 30. https://web.archive.org/web/20000504145352/http://www.sun.com/research/self… 31. https://web.archive.org/web/20010605131725/http://www.sun.com/research/self… 32. http://www.ag-nbi.de/research/dself/ 33. http://selfguru.sourceforge.net/ 34. http://ftp.squeak.org/docs/OOPSLA.Squeak.html 35. https://web.archive.org/web/20150220064600/http://www.comtalk.net/Squeak/95 36. http://merlintec.com/swiki/Self/1.html 37. http://stefan-marr.de/tag/roarvm/ 38. http://merlintec.com/lsi/tiny.html 39. https://dl.dropboxusercontent.com/u/1803213/CS294/8%20Self%20VM%20internals… 40. https://www.cs.ucsb.edu/~urs/oocsb/self/index.html <https://www.cs.ucsb.edu/%7Eurs/oocsb/self/index.html> 41. https://liveprogramming.github.io/2013/papers/avocado.pdf 42. http://c2.com/cgi/wiki?SelfLanguage 43. https://news.ycombinator.com/item?id=7047953 44. http://stackoverflow.com/questions/tagged/selflanguage 45. https://www.infoq.com/presentations/oop-language-context 46. http://xanadu.com/zigzag/ 47. http://www.nongnu.org/gzz/gi/gi.html 48. http://www.merlintec.com/download/ 49. https://learnxinyminutes.com/docs/self/ 50. http://rosettacode.org/wiki/Category:Self 51. https://vimeo.com/118826521 52. http://homepages.ecs.vuw.ac.nz/~servetto/Fool2014/FundationForObjectAspectA… <http://homepages.ecs.vuw.ac.nz/%7Eservetto/Fool2014/FundationForObjectAspec…> 53. https://www.researchgate.net/publication/285512303_Persistence_schema_evolu… 54. http://rosettacode.org/wiki/Category:Self 55. http://www.gliebe.de/self/ 56. https://web.archive.org/web/20070205114801/http://www.lsi.usp.br/~jecel/tin… <https://web.archive.org/web/20070205114801/http://www.lsi.usp.br/%7Ejecel/t…> tinyRick tinySelf 57. http://www.wolczko.com/CS294/ Next blog will contain some improvement proposals. �PNG

6 10

[Ann] A simple streaming framework
by Russell Allen 16 Jun '16

16 Jun '16

[This is a copy of the blogpost: https://blog.selflanguage.org ] have long maintained that Self is the finest Yak shaving system in existence. Everything is possible and nothing is finished :) So I was playing with building a website front end for the mailing list archives, which led me to improving the Self web server, which led me to making a new experimental stream framework for Self. This also led me to some interesting ideas on automatically checking for methods which should be present in an object but aren’t, but I’ll write about that later! Self already has a readStream and writeStream prototypes, which are very basic entities modelled largely on Smalltalk-80. They’re mainly used in the context reading and writing to files and sockets. What I’ve put together is a quick stream framework for putting together pipelines of filters etc and streaming objects through them. The general aim is to avoid the technical and conceptual overhead of copying collections multiple times as you handle them. This isn’t particularly groundbreaking, lots of other languages do this sort of thing. It’s a bit like Smalltalk’s Xtreams but much more minimal. I’d like to hear suggestions on how to make what I’ve done more elegant and Self-ish. The code is at https://github.com/russellallen/flow Basically, streams are entities which understand either readIfFail: or write:IfFail:. Streams can only be read or write. Flow streams are composable, which means you can link them in a chain with pipeable connectors. The relevant parts are in the global object ‘flow’. This isn’t optimised at all – ideally streams should cheat by copying larger chunks behind the scenes where appropriate for performance. Also file streams probably need to be more aware of reading and writing chunks with internal buffers, and string writing should be optimised to reduce copying! Possible improvements include adding spitting and merging pipes, specific buffering pipes etc. Using flow streams is a two or three step process: 1 Build structure. | myPipeline | myPipeline: 'This is a bit of text for us to play with' reading |= (flow pipeable map copyOn: [|:c| c capitalize]) |= (flow pipeable filter copyOn: [|:c| c isVowel]) |= (flow pipeable gather copyOn: [|:c| (c & c) asList]) |= flow writable string copy. 2 Put pipeline into action myPipeline flush. 3 (Optionally) convert your stream into something else [myPipeline contents = 'IIIIAAIIOOEEOOUUOOAAII'] assert. And that’s about it. I’ll play with this some more, any suggestions? Russell

2 2

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest June 2016