The SF Perl Raku Study Group, 05/05 at 1pm PDT
"Social theory is largely a game of make-believe in which we pretend, just for the sake of argument, that there's just one thing going on: essentially, we reduce everything to a cartoon so as to be able to detect patterns that would be otherwise invisible. As a result, all real progress in social science has been rooted in the courage to say things that are, in the final analysis, slightly ridiculous: the works of Karl Marx, Sigmund Freud or Claude Lévi-Strauss being only particularly salient cases in point. One must simplify the world to discover something new about it. The problem comes when, long after the discovery has been made, people continue to simplify." -- "The Dawn of Everything" (2020), David Graeber and David Wengrow The Raku Study Group May 5, 2024 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/81394187866?pwd=UDMydlQxLy9FNzhCeHBpTUR2YTV1UT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/300819351/
The SF Perl Raku Study Group, 04/21 at 1pm PDT
"The dilemma of the critic has always been that if he knows enough to speak with authority, he knows too much to speak with detachment." -- Raymond Chandler, "A Qualified Farewell" (early 1950's) The Raku Study Group April 21, 2024 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/84629149935?pwd=MmQ4QVIvVFR4VXdoWHVDZlIvYkV4QT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/300499020/
The SF Perl Raku Study Group, 04/07 at 1pm PDT
"I do not think that society ought to maltreat men of genius as it has done hitherto; but neither do I think it should indulge them too far, still less accord them any privileges or exclusive rights whatsoever; and that for three reasons: first, because it would often mistake a charlatan for a man of genius; second, because, through such a system of privileges, it might transform into a charlatan even a real man of genius, demoralize him, and degrade him; and, finally, because it would establish a master over itself." -- Mikhail Bakunin, "God and the State" (1882) The Raku Study Group April 7, 2024 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/88998480871?pwd=OFdRbnZXNXJON1kwbGpyTUgyMkYwQT09 Passcode: 4RakuRoll
The SF Perl Raku Study Group, 03/34 at 1pm PDT
Margaret Masterman, "The Nature of a Paradigm" (1970): "This pre-scientific and philosophic state of affairs sharply contrasts, however, with *multi-paradigm science*, with that state of affairs in which, far from there being no paradigm, there are on the contrary too many. (This is the present overall situation in the psychological, social and information sciences.) ... each sub-field as defined by its technique is so obviously more trivial and narrow than the field as defined by intuition, and also the various operational definitions given by the techniques are so grossly discordant with one another, that discussion on fundamentals remains, and long-run progress (as opposed to local progress) fails to occur. This state of affairs is brought to an end when someone invents a deeper, though cruder paradigm ..." The Raku Study Group March 24, 2024 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/89784337896?pwd=bjF4MmdnWU0zMUpoTndMOHVJQzVTdz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/299953269/
Re: The SF Perl Raku Study Group, 04/10 at 1pm Pacific Time
And this: > March 10th, 2024 1pm in California, 9pm in the UK Should've read "8pm in the UK". On 3/7/24, Joseph Brenner wrote: > Note: Here in the US, we are about to "spring ahead" one mooorre time, > and the 1pm I'm referring to is an hour earlier than many of you expect. > >"It's becoming increasingly unusual to read a report of a new >technology or scientific discovery that doesn't breathlessly >use the phrase 'it seems like science fiction'. The news >cycle is currently dominated by hype about artificial >intelligence (a gross mis-characterisation of machine >learning algorithms and large language models). A couple of >years ago it was breathless hype about cryptocurrency and >blockchain technologies-- which turned out to be a financial >services bubble ... " > >-- Charles Stross, November 10th, 2023, >"We're sorry we created the Torment Nexus" > > The Raku Study Group > > March 10th, 2024 1pm in California, 9pm in the UK > > An informal meeting: drop by when you can, show us what you've got, > ask and answer questions, or just listen and lurk. > > Perl and programming in general are fair game, along with Raku, > > Zoom meeting link: > > https://us02web.zoom.us/j/87052612966?pwd=cExtbzJLVkIyUGVZRGlYWlBBRTg1dz09 > > Passcode: 4RakuRoll > > RSVPs are useful, though not needed: > https://www.meetup.com/san-francisco-perl/events/299663054/ >
The SF Perl Raku Study Group, 04/10 at 1pm Pacific Time
Note: Here in the US, we are about to "spring ahead" one mooorre time, and the 1pm I'm referring to is an hour earlier than many of you expect. "It's becoming increasingly unusual to read a report of a new technology or scientific discovery that doesn't breathlessly use the phrase 'it seems like science fiction'. The news cycle is currently dominated by hype about artificial intelligence (a gross mis-characterisation of machine learning algorithms and large language models). A couple of years ago it was breathless hype about cryptocurrency and blockchain technologies-- which turned out to be a financial services bubble ... " -- Charles Stross, November 10th, 2023, "We're sorry we created the Torment Nexus" The Raku Study Group March 10th, 2024 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/87052612966?pwd=cExtbzJLVkIyUGVZRGlYWlBBRTg1dz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/299663054/
Re: disable coercing?
Would this trick help? You can define a "subset" that restricts values to the uint16 range: my subset FussyUint16 of Int where 0 ..^ 2¹⁶; my FussyUint16 $x; $x = -1; ## Type check failed in assignment to $x; expected FussyUint16 but got Int (-1)
The SF Perl Raku Study Group, 02/25 at 1pm PDT
"Over the years, executives have backed their desire to eliminate programmers with staggering funds. Dozens of simplistic schemes have been heaped with money and praise on the promise-- as yet not kept-- of going directly from sales proposal to a working data-processing system. But we should not chide these executives for their naiveté in assessing technical merits. We should applaud them in their sophistication in sensing the source of so many of our problems. Their touching faith in the magic of technology should serve as inspiration ... " Gerald M. Weinberg, "Psychology of Computer Programming" (1971) The Raku Study Group February 25, 2024 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/86800235484?pwd=UXByayt0cStZM1BUY1IzS21sY2IzQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/299388335/
The SF Perl Raku Study Group, 02/04 at 1pm PDT
John Dewey, "Logic: The Theory of Inquiry" (1938): "... the more developed this field becomes, the more pressing is the question as to what it is all about." The Raku Study Group February 4th, 2024 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/87320867624?pwd=UUNjNWx1YUp2RWdPay8zWnFydGcvUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/298981917/
The SF Perl Raku Study Group, 01/21 at 1pm PDT
"New research from the University of Washington finds that a natural aptitude for learning languages is a stronger predictor of learning to program than basic math knowledge, or numeracy." -- About the paper "Relating Natural Language Aptitude to Individual Differences in Learning Programming Languages" (2020) by Chantel S. Prat et. al. https://www.sciencedaily.com/releases/2020/03/200302103735.htm January 21, 2024 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/85922007479?pwd=VVZzMHNNMmJNanB6U3Z0RG1tb3BIZz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/298649188
The SF Perl Raku Study Group, 12/31 at 1pm PDT
Jean-Paul Sartre, "Existentialism is a Humanism" (1946): "Who, then, can prove that I am the proper person to impose, by my own choice, my conception of man upon mankind? I shall never find any proof whatever; there will be no sign to convince me of it. If a voice speaks to me, it is still I myself who must decide whether the voice is or is not that of an angel." The Raku Study Group December 31, 2023 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/82514130481?pwd=UDM4VjNaWGZBZVpZajlRK1ovNG9yUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/298203418/
The SF Perl Raku Study Group, 12/17 at 1pm PDT
Edward Gibbon, "The History of the Decline and Fall of the Roman Empire": "Thus our tender minds, fettered by the prejudices and habits of a just servitude, are unable to expand themselves, or to attain that well-proportioned greatness which we admire in the ancients." The Raku Study Group 12/17 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/81701987003?pwd=R2tpZXhJQ24rbjUrQ3lCTXl6T25wUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/297968901/
The SF Perl Raku Study Group, 12/03 at 1pm PDT
"Such fullness in that quarter overflows And falls into the basin of the mind That man is stricken deaf and dumb and blind, For intellect no longer knows Is from the Ought, or knower from the Known--" William Butler Yeats, "A Dialogue of Self and Soul" (1933) The Raku Study Group December 3, 2023 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/87023044617?pwd=Q0kyQ291aFcvSlB0TVZqNVAzVEZqUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/297707152/
The SF Perl Raku Study Group, 11/19 at 1pm PDT
"... we not only wanted to fix things that we already knew were suboptimal, but we also wanted to do a better job of responding to cultural change, because we simply don't know what we'll want in the future. So we though about how best to future proof a computer language, much of the current design is about maintaining careful control of identity, mutability, dimensionality, typology, and extensibility over time, so we could isolate changes to minimize collateral damage." -- Larry Wall, introduction to "Fundamentals of Perl 6" (2017) The Raku Study Group November 19, 2023 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/84103519076?pwd=OUs5NkxDS1Bpclcwekw5TmtZbGloUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/297438494/
The SF Perl Raku Study Group, 10/22 at 1pm PDT
"All types of knowledge ultimately mean self-knowledge." -- Bruce Lee (1971) The Raku Study Group October 22, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/82197567464?pwd=QXdpVHA1bW8za0RhQ0NnWGlUY3h5dz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/296882196/
The SF Perl Raku Study Group, 10/08 at 1pm PDT
"[Steven Mithen] describes the cultural revolution that took place about 40,000 years ago and that introduced complex multi-part tools and the elements of higher culture, including art, religion, and more complex forms of social organization. How to account for this explosion of creative activity? Mithen postulates an organically based cognitive development in which the previously separate domains of the mind became accessible to one another. He argues that the domains devoted to technical understanding, social interaction, and natural history blended together, and that out of this blend there emerged an entirely new range of creative cognitive activity. Mithen describes this new capability as 'cognitive fluidity,' and he argues cogently that it is the basis for all our more imaginative, inventive cultural achievements." Joseph Carroll, "Steven Pinker’s Cheesecake For The Mind" (1998) The Raku Study Group October 8th, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/86559548925?pwd=WHZDaVUzUjJZc2NET2RFT2JGTmh4dz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/296606549/
The SF Perl Raku Study Group, 09/24 at 1pm PDT
"Don't move your feet until the next beat comes-- One of the laws says pause between, Though I would hate to make the game seem mean ... Listen now to the sound of the Drum-- And don't forget we're nothing yet but water." -- "The Drum" (1974) by Slapp Happy The Raku Study Group September 24, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/85264211563?pwd=ek9yZXViV3NLQ1N6U25SUThCVkREdz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/296248160/
The SF Perl Raku Study Group, 09/10 at 1pm PDT
Dashiell Hammett, "The Dain Curse" (1929): "Nobody thinks clearly, no matter what they pretend. Thinking's a dizzy business, a matter of catching as many of those foggy glimpses as you can and fitting them together the best you can. That's why people hang on so tight to their beliefs and opinions; because, compared to the haphazard way in which they're arrived at, even the goofiest opinion seems wonderfully clear, sane, and self-evident." The Raku Study Group September 10th, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/89494200227?pwd=RmVNYmNaVnZTV0Z0UGRiQTE4dDgwZz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/295970581
The SF Perl Raku Study Group, 08/20 at 1pm PDT
"A choice architect has the responsibility for organizing the context in which people make decisions. ... There are many parallels between choice architecture and more traditional forms of architecture. A critical parallel is there is no such thing as a 'neutral' design. ... As good architects know, seemingly arbitrary decisions, such as where to locate the bathrooms, will have subtle influences on how the people who use the building interact." Richard H. Thaler and Cass R. Sunstein, "Nudge" (2008) The Raku Study Group August 20th, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/84128071846?pwd=Z3dSb1NaL0Rua0tNaHp4LzE0eFVudz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/295546982/
The SF Perl Raku Study Group, 08/06 at 1pm PDT
"Perseverance of one's own culture does not require contempt or disrespect for other cultures." (Commonly attributed to Cesar Chavez) The Raku Study Group August 6, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/84348100717?pwd=Y3NJRU9RNkR3bjNDaWJqRW1iRUFSUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/29551/
Raku Study Group, 07/23
Hey, anyone looking for a Raku meeting? "My brain hurts!" -- Gumby The Raku Study Group July 23, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/81025358047?pwd=VGNIemxnd21MRDVzN1NYRGlOMGFCQT09 Passcode: 4RakuRoll
The SF Perl Raku Study Group, 07/09 at 1pm PDT
>From David Byrne's "How Music Works" (2012): "I had an extremely slow-dawning insight about creation. That insight is that context largely determines what is written, painted, sculpted, sung or performed. That doesn't sound like much of an insight, but it's actually the opposite of conventional wisdom, which maintains that creation emerges out of some interior emotion, from an upwelling of passion or feeling, and that the creative urge will brook no accomodation ..." The Raku Study Group July 9th, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/83884419957?pwd=MVVGeDd1WWcxQWJsdjNuMnVuZno0dz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/294680296/
Subject: Re: Need regex in the middle wildcard help
References: Try something like this, perhaps: $x ~~ s:i/ ^ (.*?) '' .*?
The SF Perl Raku Study Group, 06/18 at 1pm PDT
"The modernist architects and urban planners declared that 'less is more,' to quote the famous twentieth-century architect Ludwig Mies van der Rohe, streamlining designs to the point of turning cities into exercises in geometry and repetition, with an endless succession of avenues, street blocks, cube-like buildings, columns, windows, and so on. The simplicity of modern architecture quickly degenerated into the Brutalist trend of unwieldy masses of concrete and glass." Mauro F. Guillén, "2030" (2020) The Raku Study Group June 18, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/83385233489?pwd=VDVWcHBZM2ZFUDZKdEVXdmpYSkZxdz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/294234119/
The SF Perl Raku Study Group, 06/04 at 1pm PDT
"In the game of life and evolution there are three players at the table: human beings, nature, and machines. I am firmly on the side of nature. But nature, I suspect, is on the side of the machines." George B. Dyson, "Darwin Among the Machines" (1997) The Raku Study Group June 4, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/89165849010?pwd=TmF1Q1lpNnNhODFZNWtwcWhUK1drZz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/293941365/
The SF Perl Raku Study Group, 05/21 at 1pm PDT
"I definitely feel that there is something rotten in the realm of programming. There is a lot of discussion, but somehow I think that most of it misses the point. There are too many fads, too many quick solutions, a too wide gap between theory and practice." -- Peter Naur, Communications of the ACM, December 1975 The Raku Study Group May 21, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/87971521654?pwd=UzhqY3AvYm5rSTNJUDY0dkJMa3RzQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/293630194/
The SF Perl Raku Study Group, 04/30 at 1pm PDT
"The thing about Computer Science is that it's not a Science, and it's not about Computers. The disicipline that's about computers is called Electrical Engineering. And Computer Science isn't a science, because for the most part we don't do experiments to find out what reality is like." -- Brian Harvey, UC Berkeley, CS 61A, Spring 2008 "The Structure and Interpretation of Computer Programs" The Raku Study Group April 30th, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku. Zoom meeting link: https://us02web.zoom.us/j/82134828016?pwd=emFyM2tHdE1XNC9QTmpNQVZVVElIUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/293180892/
The SF Perl Raku Study Group, 04/16 at 1pm PDT
"So, is 'genius' the only way to explain it? No, I'm sure there's something I can learn, even from a genius." -- Bakuman (2008-12), Vol 3, Ch 23, "Conceit and Kindness" Tsugumi Ohba & Takeshi Obata, trans. Tetsuichiro Miyaki The Raku Study Group April 16, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/82507731870?pwd=cElwL3NGVmNIUytKODhhZlUzWGl6QT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/292714459/
The SF Perl Raku Study Group, 03/26 at 1pm PDT
"The bloom is off the rose for the big tech companies. We no longer hear so much gushing about putting a library into everyone's hands, social media as a means of empowering people to challenge their governments, or tech innovators who make our lives better by disrupting old industries." "System Error" (2021) by Rob Recih, Meharan Sahami and Jeremey M. Weinstein The Raku Study Group March 26, 2023 1pm in California, 8pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/88977684101?pwd=eXBGL1R6dUVxTjJrbytrZm9URWdOdz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/292440193/
The SF Perl Raku Study Group, 03/05 at 1pm PDT
"The rarest of gifts in men, that on the one hand they should have clear, firm ideas of their own, and, on the other, that they should be able to accomodate themselves to the ideas of men differing from them and give them their due ..." -- Fritz Brupbacher on James Guillaume, from "No Gods, No Masters" edited by Daniel Guerián (1980, english translation 1998) The Raku Study Group March 5, 2023 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/86783620631?pwd=RWtxQVVIVjBMZEVoeE15bDZ1dlBnQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/291994163/
The SF Perl Raku Study Group, 02/26 at 1pm PDT
"We live surrounded by a chaos of undifferentiated factoids and half-formed allusions, and in the absence of convincing structural links, we rely on, search for, or imagine flashes, intuitions, hovering conceptual affinities, and hyperbolic recurrences that can be explained only by accumulated karma from previous lifetimes or pure unadulterated random chance." -- Peter Sellars, forward to Chris Salter's "Entangled" (2010), "Technology and the Transformation of Performance" The Raku Study Group February 26, 2023 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/88624609762?pwd=RXU4ek5xdEtzd3kxbUlHcXZybU1sZz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/291832186/
The SF Perl Raku Study Group, 02/12 at 1pm PDT
Samuel Taylor Coleridge, "The Destiny of Nations" (1817): "But some there are who deem themselves most free When they within this gross and visible sphere Chain down the winged thought, scoffing ascent, Proud in their meanness; and themselves they cheat With noisy emptiness of learned phrase, Their subtle fluids, impacts, essences, Self-working tools, uncaused effects, and all ... " The Raku Study Group February 12, 2023 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/85069842220?pwd=aCtjdFQ4Y0JpcTBOc3JJeFZRYVlHdz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/291526050/
The SF Perl Raku Study Group, 01/29 at 1pm PDT
George Sand to Gustave Flaubert, November 29th, 1866: "I have never ceased to wonder at the way you torment yourself over your writing. Is it just fastidiousness on your part? There is so little to show for it... As to style, I certainly do not worry myself, as you do, over that. The wind bloweth as it listeth through my old harp." The Raku Study Group January 29, 2023 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/85019303942?pwd=NDd4YmJpZ1YzZGE5QmRvTnlybVNJUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/291222813/
The SF Perl Raku Study Group, 01/15 at 1pm PDT
"Hermes the messenger helps us glimpse the powerful archetypal connections between magic, tricks, and technology. But the god does not bloom into a genuine Promethean technomage until he heads south, across the wine dark sea, to Egypt. Here, in the centuries before the birth of Jesus, the religious imagination of the Hellenistic world crossbred Hermes with the Egyptian scribal god Thoth to create one of the great matinee idols of esoteric lore: Hermes Trismegistus." -- Erik Davis, "Techgnosis" (1998) The Raku Study Group January 15, 2023 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/84797013762?pwd=R0FHY0ZBQytYWVlmWEdTS1Fncjkydz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/290859058/
The SF Perl Raku Study Group, 01/01 at 1pm PDT
"Looking up at the purple panorama of the galaxy highway, a shooting star pierces my heart" -- "Macross 7" (1994), "Seventh Moon" by Fire Bomber, The Raku Study Group. January 1st, 2023 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku, Zoom meeting link: https://us02web.zoom.us/j/83275730318?pwd=RjU1UElmMlJrdmlTQS9rM215SExqZz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/290500952/
The SF Perl Raku Study Group, 12/18 at 1pm PDT
"Is it any wonder if we at last grow distrustful, lose patience, and turn impatiently away? That this Sphinx teaches us at last to ask questions ourselves?" -- Nietzsche, "Beyond Good and Evil", trans. Helen Zimmern The Raku Study Group December 18, 2022 1pm in California, 9pm in the UK An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Along with Raku, Perl and programming in general are fair game. Zoom meeting link: https://us02web.zoom.us/j/85239045587?pwd=TVlrTy9GOHEyZytpMkY3bzN6dTkzUT09 Passcode: 4RakuRoll
The SF Perl Raku Study Group (postponed)
On the next few Sundays, I've got some schedule conflicts, so I've got to skip holding the Raku Study Group when we usually would on December 4th. Instead the next meeting will be on December 18th, and after that we'll most likely do one on New Years Day itself, January 1st, 2023.
The SF Perl Raku Study Group, 11/20 at 1pm PDT
"They're all like 20-year old single Silicon Valley men, of course they're afraid of commitment." -- Matt S. Trout, on the pletheroa of Javascript libraries "ES6: Almost an Acceptable Perl5?" (2017) The Raku Study Group: An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Along with Raku, Perl and programming in general are fair game. November 20, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/82235449629?pwd=ODFGMDlxRHlYSzZwOTJUcE9GNnVYUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/289822586/
The SF Perl Raku Study Group, 10/06 at 1pm PDT
"The FSF software distribution has added a third tape. The old Compiler tape has been split into a Languages and a Utilities tape. Some software has also moved from the Emacs tape to the other two tapes ..." --"GNU's Bulletin" (1992) The Raku Study Group November 6, 2022 1pm in California, 9pm in the UK (Note: here in the US we will be celebrating what may be the last ever "fall back", so that 1pm is an hour later than the previous day's 1pm) Zoom meeting link: https://us02web.zoom.us/j/87472315832?pwd=K2wwcktDbGVnQTNUMnF5SnNZbWN5QT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/289504476/ An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku,
The SF Perl Raku Study Group, 10/23 at 1pm PDT
"None of us can fully realize what the minds of corporations are, any more than one of my brain-cells can know what the whole brain is thinking." -- C. S. Peirce, "Man's Glassy Essence" (1892) The Raku Study Group October 23, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/83335355181?pwd=dk1jZG1KYUpQcmJHQkN5MlRXUFJwUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/289262351/ An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku,
The SF Perl Raku Study Group, 10/09 at 1pm PDT
Now I tell you a secret Don't hammer on the keys For a little pianissimo is always bound to please. -- Marlene Dietrich & Hollander Victor, "Naughty Lola" (1930) The Raku Study Group October 9, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/89711010019?pwd=U3ZOREJERWxVR0xGY1p1cUsvZXlZdz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/288970320/ An informal meeting: drop by when you can, show us what you've got, ask and answer questions, or just listen and lurk. Perl and programming in general are fair game, along with Raku,
The SF Perl Raku Study Group, 09/25 at 1pm PDT
"Excursions in Number Theory" by Ogilvy and Anderson (1966): "Until recent years the binary system was looked upon as something of a mathematical curio of only theoretical importance. Suddenly it has become indispensable, and would have had to be developed in a hurry had it not been ready to hand. This has been the story again and again throughout the history of mathematics: no part of mathematics is ever, in the long run, 'useless.' Most of number theory has very few 'practical' applications. That does not reduce its importance, and if anything it enhances its fascination. No one can predict when what seems to be a most obscure theorem may suddenly be called upon to play some vital and hitherto unsuspected role." (Ten years later, Diffie-Hellman public key cryptography was published.) The Raku Study Group September 25, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/84036607818?pwd=cW5pZ2x1dzFNaHFWQnNDcjZ3ZWFjQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/288660627/
The SF Perl Raku Study Group, 09/11 at 1pm PDT
"Ventnor's father had been destroyed for gadgeteering and it was apparent that this tendency had been carried forward to the next generation. Worse, although latent, the characteristic was predominent and increasing." Philip E. High, "These Savage Futurians" (1967) The Raku Study Group September 11, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/85011544485?pwd=UnlkY24wc3hqQUtSOTFKTSsweUhuQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/288362105/
The SF Perl Raku Study Group, 08/21 at 1pm PDT
"Look out honey, 'cause I'm using technology Ain't got time to make no apology" -- Iggy Pop, "Search and Destroy" (1973) The Raku Study Group August 21, 2022 1pm in California, 9pm in the UK, 4am in Bali Zoom meeting link: https://us02web.zoom.us/j/86108934482?pwd=MzNFQ1ptQWRBNm00aklUeVdSRFNGZz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/287834284/
The SF Perl Raku Study Group, 08/07 at 1pm PDT
Walt Whitman, "Democratic Vistas" (1871): "... ahead, though dimly yet, we see, in vistas, a copious, sane, gigantic offspring." The Raku Study Group August 7, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/83144051426?pwd=UTVhclVPeVJlM0k0M3FNN1JqNXg0Zz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/287625950/
The SF Perl Raku Study Group, 07/24 at 1pm PDT
"Coevolution and symbiosis are fundamentally about relationships, and those change over time. A pet rat, a lab rat, a plague of rats and rats of unusual size all have different relationships with human beings, but they're all rats, and we're all humans." Frank Landis, "Hot Earth Dreams" (2016) The Raku Study Group. July 24th, 2020 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/85209304493?pwd=YWJrdEJ3ZGhRYkRScDdOUllTbzlaUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/287317179/
The SF Perl Raku Study Group, 07/10 at 1pm PDT
"The sciences, even the best,-- mathematics and astronomy,-- are like sportsmen, who seize whatever prey offers, even without being able to make any use of it." --Ralph Waldo Emerson, "Plato, or, the Philosopher" The Raku Study Group July 10, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/85610768539?pwd=blZVMzhZVENSQTRtQ21tN0VleHNGUT09 Passcode: 4RakuRoll https://www.meetup.com/san-francisco-perl/events/287108626/
The SF Perl Raku Study Group, 06/19 at 1pm PDT
Frederick P. Brooks, from the additional material in the 1995 edition of "The Mythical Man-Month" (1975): "Much more is known today about software engineering than was known in 1975. Which of the assertions in the original 1975 edition have been supported by data and experience? Which have been disproved? Which have been obsoleted by a changing world? ... " "Most of these propositions are operationally testable. my hope in putting them forth in stark form is to focus readers' thoughts, measurements, and comments." The Raku Study Group June 19th, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/88131904373?pwd=UXh4eko4c1pHK2llQTlIcnN5dnJpQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/286635701/
Re: The SF Perl Raku Study Group, 06/05 at 1pm PDT
Let's try that again, without the typo on the date in the message body: it's on Sunday, June *5th*. "Language is an artifact." Guru Lou Fonghoo Step 35 of the 85 steps of Fonghoosim (1972) The Raku Study Group June 5th, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/83136957677?pwd=WXRSRkZ0SjZ4aGNJZ2l1OWM3OExqQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/286342049
The SF Perl Raku Study Group, 06/05 at 1pm PDT
"Language is an artifact." Guru Lou Fonghoo Step 35 of the 85 steps of Fonghoosim (1972) The Raku Study Group June 6th, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/83136957677?pwd=WXRSRkZ0SjZ4aGNJZ2l1OWM3OExqQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/san-francisco-perl/events/286342049
The SF Perl Raku Study Group, 05/22 at 1pm PDT
Colin McPhee, "A House in Bali" (1944-47): "Beside the palm-leaf books which he had been working on the day before there lay a little fan of blossoms. "How do you honour books in America? Durus asked as he set a lamp on the table. A large mantis flew out of the dark and settled in the circle of light. "I found it hard to explain." The Raku Study Group May 22, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/88470112234?pwd=RUFwTy9Qd2NCdGZGdldielJyZi9zQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/286018197/
The SF Perl Raku Study Group, 05/08 at 1pm PDT
Herbert A. Simon, "The Sciences of the Artificial" (1969): "Since there are now many such devices in the world, and since the properties that describe them also appear to be shared by the human central nervous system, nothing prevents us from developing a natural history of them. We can study them as we would rabbits or chipmunks and discover how they behave under different patterns of environmental stimulation." The Raku Study Group May 8, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/82957926647?pwd=MlFISnUydDY2OStFbjdQMWliYkV6QT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/285726547
The SF Perl Raku Study Group, 10/24 at 1pm PDT
Jane Jacobs, "The Death and Life of Great American Cities" "Cities are an immense laboratory of trial and error, failure and success, in city building and city design. This is the laboratory in which city planning should have been learning and forming and testing its theories. Instead the practitioners and teachers of this discipline (if such it can be called) have ignored the study of success and failure in real life, have been incurious about the reasons for unexpected success, and are guided instead by principles derived from the behavior and appearance of towns, suburbs, tuberculosis sanatoria, fairs, and imaginary dream cities-- from anything but cities themselves." The Raku Study Group April 24, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/84615668722?pwd=ZlVYb1FKOHRsUU5ROVFsdnE1SzZDQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/285404729
The SF Perl Raku Study Group, 04/10 at 1pm PDT
"I could see the writing on the wall. It was my handwriting." Jean Michel-Basquiat, "Downtown 81" The Raku Study Group April 10, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/88273860585?pwd=eks5ZWFrNmdrTGF3VWFNVWtENkxmUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/<>
The SF Perl Raku Study Group, 03/27 at 1pm PDT
Paul Linebarger, "Psychological Warfare" (1947): "Europeans described light, hard-hitting *numerically inferior* cavalry as a 'numberless horde' because Mongol agents whispered such a story in the streets. To this day most Europeans do not appreciate the lightness of the forces nor the cold intelligence of command with which the Mongols hit them seven centuries ago." The Raku Study Group March 27, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/84884169514?pwd=OWlrc1FDWGluVEkwU1QzelZURjdiUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/284841443
Re: The SF Perl Raku Study Group, 03/22 at 1pm PDT
> March 13, 2022 1pm in California, 9pm in the UK Sorry, but thanks to the magic of "daylight savings time", 1pm in California is an hour earlier today, and that "9pm in the UK" should've said 8pm.
The SF Perl Raku Study Group, 03/22 at 1pm PDT
Randall Munroe, "Excel Lambda": "The Church-Turing thesis says that all ways of computing are *equally* wrong." https://xkcd.com/2453/ The Raku Study Group March 13, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/89011730967?pwd=RWxrbEdaWWN6eUE5RHByRzBPVlJqUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/284562056/
The SF Perl Raku Study Group, 02/27 at 1pm PDT
Poul Anderson, "Harvest the Fire" (1995): "Why this jagged distribution of greatness? The incidence of innate abilities could scarcely vary that much. The social situation, the _Zeitgeist_-- were such phrases anything but noises?" The Raku Study Group February 17, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/81577367208?pwd=L3kxT0ZoSlh3SXVLTzBnS053ZmZkdz09w Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/284255643/
The SF Perl Raku Study Group, 02/13 at 1pm PDT
Lera Boroditsky, "How does our language shape the way we think" (2009): We have collected data around the world: from China, Greece, Chile, Indonesia, Russia, and Aboriginal Australia. What we have learned is that people who speak different languages do indeed think differently and that even flukes of grammar can profoundly affect how we see the world. The Raku Study Group February 13, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/84159205141?pwd=UkFta3NVL1dXVHhwSjEzZUF3a3dMZz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/283871691/
The SF Perl Raku Study Group, 01/30 at 1pm PDT
David Auerbach, "Bitwise: A Life in Code" (2018): "As a child, I had been drawn to computers because they were free of society's tortuous value systems. Ironically, I now live in a world where computers are the thoughtless arbiters of those very same value systems. They have come to speak our languages like idiots, replicating their stigmas and biases." The Raku Study Group January 30, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/86424672986?pwd=ckdNY05uRXFpa3VBdzRtWVNNVFJ1dz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/283555401/
The SF Perl Raku Study Group, 01/16 at 1pm PDT
Gary Snyder, "A Space in Place" (1996), "Language Goes Two Ways": " 'Wild' alludes to a process of self-organization that generates systems and organisms ... Wildness can be said to be the essential nature of nature. As reflected in consciousness, it can be seen as a kind of open awareness-- full of imagination but also the source of alert survival intelligence. The workings of the human mind at its very richest reflect this self-organizing wildness. " The Raku Study Group January 16, 2022 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/86967710658?pwd=YWhndVcxZGVCOE45WHUxdmg3M1lPZz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/283249800/
The SF Perl Raku Study Group, 01/02 at 1pm PDT
Heraclitus, translated by William Harris: From many things comes oneness, and out of oneness comes many things. The hidden harmony is better than the obvious. The Raku Study Group January 2, 2021 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/89182070922?pwd=Y05wV0tVakk1TUpvd21acDcrV2RGZz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/282992445/ Happy New Year all, and see you tomorrow if you're up for it.
The SF Perl Raku Study Group, 12/19 at 1pm PDT
James Baldwin, "The Fire Next Time" (1963): "In all jazz, and especially the blues, there is something tart and ironic, authoritative and double-edged. White Americans seem to feel that happy songs are happy and sad songs are sad, and that, God help us, is exactly the way most white Americans sing them ..." The Raku Study Group December 19, 2021 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/82770320540?pwd=L1hscy9wVDhobFFwZWFmQksrZDliZz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/282697483/
The SF Perl Raku Study Group, 11/21 at 1pm PDT
Ibsen, "Peer Gynt" (1867): "'Go round about', said the Boyg. So I must." The Raku Study Group November 21, 2021 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/86710457729?pwd=NDRDd0V2ek9DZ1RKLzlPRUtWek1aQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/282196143/
Re: The SF Perl Raku Study Group, 11/07 at 1pm PDT
That's a thought, but we haven't tried that one yet. On 11/7/21, Walt Pang wrote: > Is there a youtube channel for recording this? > > regards. > > On Mon, Nov 8, 2021 at 1:00 AM Joseph Brenner wrote: > >> > 11/07 1pm in California, 8pm in the UK >> >> Oops. Actually more like 7pm in the UK. >> >> >> >> >> On 11/4/21, Joseph Brenner wrote: >> > Susan Sontag's "On Camp" (1964): >> > >> > "Camp taste is a kind of love, love for human >> >nature. It relishes, rather than judges, the little >> >triumphs and awkward intensities of 'character.'" >> > >> > The Raku Study Group >> > >> > 11/07 1pm in California, 8pm in the UK >> > >> > Zoom meeting link: >> > >> > >> https://us02web.zoom.us/j/84546628718?pwd=bUFaL3plcW9JREFxZy9OWDFDQnNBQT09 >> > >> > Passcode: 4RakuRoll >> > >> > RSVPs are useful, though not needed: >> > https://www.meetup.com/San-Francisco-Perl/events/281872277/ >> > >> >
Re: The SF Perl Raku Study Group, 11/07 at 1pm PDT
> 11/07 1pm in California, 8pm in the UK Oops. Actually more like 7pm in the UK. On 11/4/21, Joseph Brenner wrote: > Susan Sontag's "On Camp" (1964): > > "Camp taste is a kind of love, love for human >nature. It relishes, rather than judges, the little >triumphs and awkward intensities of 'character.'" > > The Raku Study Group > > 11/07 1pm in California, 8pm in the UK > > Zoom meeting link: > > https://us02web.zoom.us/j/84546628718?pwd=bUFaL3plcW9JREFxZy9OWDFDQnNBQT09 > > Passcode: 4RakuRoll > > RSVPs are useful, though not needed: > https://www.meetup.com/San-Francisco-Perl/events/281872277/ >
Re: junctions with given/when
Yes, this feels like natural Raku code to a lot of us:
given any( $o1, $o2 ) { when { ... } }
If there's some rule like, "don't use junctions
on the left hand side of a smartmatch" that
hasn't been made clear, and there's certainly no
roast tests that check this, so consequently the
behavior has drifted around.
The latest word from Jonathan Worthington seems
to be that the current behavior should probably
be reverted *for now*, but a later language
version of Raku will change it again, albeit more
consistently.
So if you were serious about writing Raku code
(and not just playing around with it, as I mostly am)
you'd need to have a list in mind of these things
that are kinda-sorta-deprecated. Otherwise, you'd
just have to expect breakage on upgrade in the future.
On 11/4/21, yary wrote:
> and I realize that what I just typed doesn't help a whole lot, what if you
> have a junction of things and you want to tell if any/one/all/none
> smartmatch the same thing... OK..
>
> -y
>
>
> On Thu, Nov 4, 2021 at 6:38 PM yary wrote:
>
>> Something that helps me reason about this is thinking of how regular
>> expressions match against strings, to remember that which goes on which
>> side is important...
>>
>> > "this has a Q in it" ~~ / 'Q' / # of course this works
>>
>> ｢Q｣
>>
>> > / 'Q' / ~~ "this has a Q in it" # of course this breaks
>>
>> Regex object coerced to string ...
>>
>>
>> > say do given "this has a Q in it" { when / 'Q' / {"has a Q"}; default
>> {"no match"}}
>>
>> has a Q
>>
>> > say do given / 'Q' / { when "this has a Q in it" {"has a Q"}; default
>> {"no match"}}
>>
>> Regex object coerced to string ...
>>
>> I did have a place in the earlier discussion. I eventually realized that
>> if I thought of junctions as analogous to regular expressions, then it
>> was
>> easier to remember which side of the smartmatch or given/when to put it.
>>
>> -y
>>
>>
>> On Thu, Nov 4, 2021 at 3:31 PM Joseph Brenner wrote:
>>
>>> > ... we'd need to go
>>> > through detailed, calm, measured discussion if we're to minimize
>>> > the pain it seems we'll inevitably endure pain to dig ourselves out
>>> > of the hole we'd be in.
>>>
>>> Yes, this could be a bad one.
>>>
>>
>
The SF Perl Raku Study Group, 11/07 at 1pm PDT
Susan Sontag's "On Camp" (1964): "Camp taste is a kind of love, love for human nature. It relishes, rather than judges, the little triumphs and awkward intensities of 'character.'" The Raku Study Group 11/07 1pm in California, 8pm in the UK Zoom meeting link: https://us02web.zoom.us/j/84546628718?pwd=bUFaL3plcW9JREFxZy9OWDFDQnNBQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/281872277/
Re: junctions with given/when
> ... we'd need to go > through detailed, calm, measured discussion if we're to minimize > the pain it seems we'll inevitably endure pain to dig ourselves out > of the hole we'd be in. Yes, this could be a bad one.
Re: junctions with given/when
Yes, thanks, I'd managed to forget that we had a go-round on this one six months ago, even though that one came out of the Raku Study Group I run. I'm actually finding this one profoundly depressing, but I probably shouldn't get into it. My thoughts are running along lines like "how is it possible something like this is still up-in-the-air at this date?" and "is this language too complex to be implemented cleanly?" and so on. On 11/4/21, Ralph Mellor wrote: > Aiui, we discussed this issue in May and Larry explained > that this would happen. > > Larry doesn't speak up much, and I realized a few months > later that it seemed no one had done anything about what > he had said. So I filed an issue: > > https://github.com/Raku/problem-solving/issues/297 > > Aiui, until we listen to Larry, accept he's right, and fix Rakudo, > the results when the topic of a smart match is a Junction will > randomly depend on which version of Rakudo you're using. > > -- > love, raiph >
The SF Perl Raku Study Group, 11/07 at 1pm PDT
Susan Sontag's "On Camp" (1964): "Camp taste is a kind of love, love for human nature. It relishes, rather than judges, the little triumphs and awkward intensities of 'character.'" The Raku Study Group 11/07 1pm in California, 8pm in the UK Zoom meeting link: https://us02web.zoom.us/j/84546628718?pwd=bUFaL3plcW9JREFxZy9OWDFDQnNBQT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/281872277/
Re: junctions with given/when
Joseph Brenner wrote:
> Andy Bach wrote:
>> Joseph Brenner wrote:
>>> I'd thought that that [this] would confirm that both elements were Int:
>>> say do given all(3,7) { when Int { "both are Int" }; default {"not
>>> similar"} };
>>> ## not similar
>> I get a different result
>> $ raku -e ' say do given all(3,7) { when Int { "both are Int" }; default
>> {"not similar"} };'
>> both are Int
>> $ raku -v
>> This is Rakudo version 2020.05.1 built on MoarVM version 2020.05
> That's interesting. I just re-built from github and I'm still
> seeing the behavior I reported:
>
> raku -e 'say do given all(3,7) { when Int { "both are Int" }; default {"not
> similar"} };'
> not similar
> raku --version
> Welcome to Rakudo™ v2021.10-43-ga8329f6fd.
But if I run with an older installation, using 퐑퐚퐤퐮퐝퐨 v2020.10,
I see it work correctly. This is looking like a bug introduced
fairly recently.
I opened an issue on this:
https://github.com/rakudo/rakudo/issues/4615
Re: junctions with given/when
That's interesting. I just re-built from github and I'm still
seeing the behavior I reported:
raku -e 'say do given all(3,7) { when Int { "both are Int" };
default {"not similar"} };'
not similar
That's with:
raku --version
Welcome to Rakudo™ v2021.10-43-ga8329f6fd.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2021.10-22-g938098118.
On 11/2/21, Andy Bach wrote:
>> I'd thought that that would confirm that both elements were Int:
> say do given all(3,7) { when Int { "both are Int" }; default {"not
> similar"} };
> ## not similar
>
> I get a different result
> $ raku -e ' say do given all(3,7) { when Int { "both are Int" }; default
> {"not similar"} };'
> both are Int
>
> $ raku -e ' say do given all(3,"x") { when Int { "both are Int" }; default
> {"not similar"} };'
> not similar
>
> $ raku -e ' say do given all(3,7) { when Int { $_ }; default {"not
> similar"} };'
> all(3, 7)
>
> $ raku -v
> This is Rakudo version 2020.05.1 built on MoarVM version 2020.05
>
> From: Joseph Brenner
> Sent: Tuesday, November 2, 2021 11:45 AM
> To: perl6-users
> Subject: junctions with given/when
>
> CAUTION - EXTERNAL:
>
>
> A given/when construct using a junction isn't quite doing what I'd expect.
>
> I'd thought that that would confirm that both elements were Int:
>
> say do given all(3,7) { when Int { "both are Int" }; default {"not
> similar"} };
> ## not similar
>
> But this does what I thought it would:
>
> say so do all(3,7) ~~ Int;
> # True
>
> And the given seems to put the junction in $_ as expected:
>
> given all(3,7) { say $_; say $_.WHAT; }
> # all(3, 7)
> # (Junction)
>
> And you can use that junction in a smartmatch explicitly
>
> given all(3,7) { say so $_ ~~ Numeric; }
> # True
> CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary.
> Exercise caution when opening attachments or clicking on links.
>
>
junctions with given/when
A given/when construct using a junction isn't quite doing what I'd expect.
I'd thought that that would confirm that both elements were Int:
say do given all(3,7) { when Int { "both are Int" }; default {"not
similar"} };
## not similar
But this does what I thought it would:
say so do all(3,7) ~~ Int;
# True
And the given seems to put the junction in $_ as expected:
given all(3,7) { say $_; say $_.WHAT; }
# all(3, 7)
# (Junction)
And you can use that junction in a smartmatch explicitly
given all(3,7) { say so $_ ~~ Numeric; }
# True
The SF Perl Raku Study Group, 10/24 at 1pm PDT
Walt Whitman, "Song of Myself 6" (1892): "Or I guess it is a uniform hieroglyphic, And it means, Sprouting alike in broad zones and narrow zones ..." The Raku Study Group October 24th, 2021 1pm in California, 8pm in the UK Zoom meeting link: https://us02web.zoom.us/j/88521532673?pwd=bjZDQ2RlM2UzbS9sVy9Ld01XUTl2UT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/281579372/
The SF Perl Raku Study Group, 10/10 at 1pm PDT
Douglaus Englebart "Augmenting Human Intellect" (1962): "Although the size of the step a human being can take in comprehension, innovation, or execution is small in comparison to the over-all size of the step needed to solve a complex problem, human beings nevertheless do solve complex problems." The Raku Study Group October 10, 2021 1pm in California, 8pm in the UK Zoom meeting link: https://us02web.zoom.us/j/84161554567?pwd=SE45WWh5TGtJRDJNejl4aHFTU2p5Zz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/281254279/
Re: Order of multi sub definitions can resolve dispatch ambiguity
Joseph Brenner wrote: > And now Jonathan Worthington has announced that the new > Multi-dispatch mechanism is done... any bets on whether > any of this behavior will change? I don't see any change in this behavior using a fresh build from github.
Re: Order of multi sub definitions can resolve dispatch ambiguity
Like I was saying:
> If the two [multis] are defined in different modules I suspect you
> could get some strange behavior that would be hard to debug.
> It's not always immediately obvious in what order two things were
> defined.
Here's an example, scattered across four files, which
I've also pushed out to github:
https://github.com/doomvox/raku-study/blob/main/md_exp/
The deal here is one script treats "godzilla" as a Hero,
the other as a Monster, and the only difference is the
order of two "use" lines:
---
md_exp/lib/Speak/Monster.rakumod:
module Speak::Monster {
my @monsters = < godzilla gammera ghidora golem>;
subset Monster of Str where { $_ eq any( @monsters ) };
multi sub speak (Monster $name) is export {
say "The monster, $name roars!";
}
}
---
md_exp/lib/Speak/Hero.rakumod:
module Speak::Hero {
my @heroes= < godzilla beowulf ultraman inframan >;
subset Hero of Str where { $_ eq any( @heroes ) };
multi sub speak (Hero $name) is export {
say "The hero, $name shouts!";
}
}
---
md_exp/bin/multidispatch_overlapping_subsets_use_order_dependency-a.raku
use lib $*PROGRAM.parent(2).add("lib");
{
say "a: Hero Monster trial run";
use Speak::Hero;
use Speak::Monster;
speak('godzilla');## The hero, godzilla shouts!
}
---
md_exp/bin/multidispatch_overlapping_subsets_use_order_dependency-b.raku
use lib $*PROGRAM.parent(2).add("lib");
{
say "a: Monster Hero trial run";
use Speak::Monster;
use Speak::Hero;
speak('godzilla');## The monster, godzilla roars!
}
---
But the situation is even worse than this: the
order-of-definition doesn't depend on the order of the
use lines in the block of code in front of you:
in a large code base you might have use lines scattered
in different places, and the order-of-definition is the
order in which raku first sees the use lines.
Re: Order of multi sub definitions can resolve dispatch ambiguity
I'm not entirely sure what you're getting at with that example.
I was particularly interested in cases where there's some
ambiguity in multi-dispatch for particular values, where there's
some overlapping coverage between the prototypes.
Just for the hell of it, I'll stick another example at
the bottom of this message using numeric ranges this
time.
And it isn't exactly the way I *want* it to work, it's the way I
thought it was documented to work. I think I can see problems
with doing it either way:
If you use order-of-definition to resolve some of the difficult
cases, you have a situation where it can matter what order raku
has encountered the multi definitions. Twiddling the order of
"use" lines could produce unexpected behavior... and there's some
risk of action-at-a-distance confusion: a new "use" line added in
a remote part of the code might effect the behavior of code you
thought you had working.
But if you give up on using order-of-definition, and the "is default"
tie-breaker is the only hint you have to resolve ambiguities,
what do you do if you've got ambiguity for different values in
*three* different cases? If you make A "is default" to resolve
an ambiguity with B, what do you do about an ambiguity between B
and C? You could apply "is default" to C, but that's no good if
you also had ambiguities between A and C.
(I think in practice I'd contrive some more complicated
subset/where checks that resolve the ambiguities before handing
it off to multi-dispatch...)
By the way, I don't see any reference to these sort of
things here:
https://raku.org/archive/doc/design/apo/A12.html
I also don't see anything that exercises these cases here:
roast/S12-subset/subtypes.t
roast/S12-subset/multi-dispatch.t
And now Jonathan Worthington has announced that the new
Multi-dispatch mechanism is done... any bets on whether
any of this behavior will change?
As promised above, yet another example, this one using
overlapping numeric ranges via where clauses. Here the
order of the multis resolves the ambiguous case "4":
{
multi sub check_range ( Int $n where {$_ > 3} ) {
return "over 3";
};
multi sub check_range ( Int $n where {$_ < 5} ) {
return "under 5";
};
say "2: ", check_range(2); # 2: under 5
say "7: ", check_range(7); # 7: over 3
say "4: ", check_range(4); # 4: over 3
}
say "===";
{
multi sub check_range ( Int $n where {$_ < 5} ) {
return "under 5";
};
multi sub check_range ( Int $n where {$_ > 3} ) {
return "over 3";
};
say "2: ", check_range(2); # 2: under 5
say "7: ", check_range(7); # 7: over 3
say "4: ", check_range(4); # 4: under 5
}
On 9/25/21, Brad Gilbert wrote:
> On Sat, Sep 25, 2021 at 2:30 PM Joseph Brenner wrote:
>
>> > Since subsets are just code it would be difficult to impossible
>> > to determine all of the ones that can match without actually
>> > running them all. This would slow down every call that uses
>> > multiple subsets.
>>
>> I can see how there would be a big performance hit, but I haven't
>> yet turned up any reference to this behavior in the docs. I
>> don't see anything to clue you in that subsets are an exception,
>> and I don't think there's anything about
>> order-of-definition-of-sub being a tie-breaker under any
>> circumstances.
>>
>
> The docs are not the definitive source of truth.
> They are at best an approximation.
>
>> By most narrow candidate, it means by type.
>>
>> If you'd said that to me, I'd still have expected it to work the
>> way that I did, because the way I look at it I'm creating new
>> types via subset.
>>
>
> By type I mean something that can be instantiated or subclassed.
> Subsets cannot do either of those two things.
> You can create a subset of a subset, but that is not the same thing.
>
>
>> > All subsets "of" the same type are sorted by the order they are
>> > written.
>>
>> Even if I'd figured that two subsets of Str were going to treated as Str,
>> I'd have expected an "Ambiguous call" error.
>>
>> If the two subsets are defined in different modules I suspect you
>> could get some strange behavior that would be hard to debug.
>> It's not always immediately obvious in what order two things were
>> defined.
>>
>
> Doing what you want would make using subsets with multis much less useful.
>
> multi factorial ( 0 --> 1 ){}
> multi factorial ( 1 --> 1 ){}
> multi factorial ( UInt \n ){ factorial(n - 1) * n }
>
> say factorial( 1 );
> # ERROR: bot
Re: Order of multi sub definitions can resolve dispatch ambiguity
> Since subsets are just code it would be difficult to impossible
> to determine all of the ones that can match without actually
> running them all. This would slow down every call that uses
> multiple subsets.
I can see how there would be a big performance hit, but I haven't
yet turned up any reference to this behavior in the docs. I
don't see anything to clue you in that subsets are an exception,
and I don't think there's anything about
order-of-definition-of-sub being a tie-breaker under any
circumstances.
> By most narrow candidate, it means by type.
If you'd said that to me, I'd still have expected it to work the
way that I did, because the way I look at it I'm creating new
types via subset.
> All subsets "of" the same type are sorted by the order they are
> written.
Even if I'd figured that two subsets of Str were going to treated as Str,
I'd have expected an "Ambiguous call" error.
If the two subsets are defined in different modules I suspect you
could get some strange behavior that would be hard to debug.
It's not always immediately obvious in what order two things were
defined.
On 9/24/21, Brad Gilbert wrote:
> This is intended behavior.
>
> Since subsets are just code it would be difficult to impossible to
> determine all of the ones that can match without actually running them all.
> This would slow down every call that uses multiple subsets.
>
> By most narrow candidate, it means by type. All subsets "of" the same type
> are sorted by the order they are written.
>
> The ambiguity it talks about is when two candidates have the same level of
> type for a given input. For example Str and Int for an IntStr.
>
>
> On Fri, Sep 24, 2021, 1:32 AM Joseph Brenner wrote:
>
>> This code uses multi dispatch with constraints that are ambiguous
>> in a few cases, because there's some overlap in the lists of
>> monsters and heroes: 'mothera' and 'godzilla'.
>>
>> my @monsters = < godzilla mothera ghidora gammera golem
>> wormface >;
>> my @heroes = < beowulf bluebeetle bernie mothera godzilla
>> maynard_g_krebs >;
>>
>> subset Monster of Str where { $_ eq any( @monsters ) };
>> subset Heroof Str where { $_ eq any( @heroes ) };
>>
>> ## Monster is favored over Hero because of the order of definition
>> of these multi subs
>> multi sub speak (Monster $m) {
>> say "The monster, $m roars!";
>> }
>> multi sub speak (Hero $h) {
>> say "The hero, $h shouts!";
>> }
>>
>> speak('ghidora'); # The monster, ghidora roars!
>> speak('beowulf'); # The hero, beowulf shouts!
>> speak('mothera'); # The monster, mothera roars!
>>
>> I would've expected that in the case of 'mothera', this would
>> error out unless an "is default" was added to one of the multi
>> subs. Instead the ambiguity is resolved by the order of
>> definition: if you reverse the order of the "multi sub speak"s,
>> then mothera is treated as Hero not Monster.
>>
>> This is not the behavior described in the documentation:
>>
>> https://docs.raku.org/language/glossary#index-entry-Multi-Dispatch
>> Multi-dispatch§
>>
>> The process of picking a candidate for calling of a set of
>> methods or subs that come by the same name but with different
>> arguments. The most narrow candidate wins. In case of an
>> ambiguity, a routine with is default trait will be chosen if
>> one exists, otherwise an exception is thrown.
>>
>
Order of multi sub definitions can resolve dispatch ambiguity
This code uses multi dispatch with constraints that are ambiguous
in a few cases, because there's some overlap in the lists of
monsters and heroes: 'mothera' and 'godzilla'.
my @monsters = < godzilla mothera ghidora gammera golem
wormface >;
my @heroes = < beowulf bluebeetle bernie mothera godzilla
maynard_g_krebs >;
subset Monster of Str where { $_ eq any( @monsters ) };
subset Heroof Str where { $_ eq any( @heroes ) };
## Monster is favored over Hero because of the order of definition
of these multi subs
multi sub speak (Monster $m) {
say "The monster, $m roars!";
}
multi sub speak (Hero $h) {
say "The hero, $h shouts!";
}
speak('ghidora'); # The monster, ghidora roars!
speak('beowulf'); # The hero, beowulf shouts!
speak('mothera'); # The monster, mothera roars!
I would've expected that in the case of 'mothera', this would
error out unless an "is default" was added to one of the multi
subs. Instead the ambiguity is resolved by the order of
definition: if you reverse the order of the "multi sub speak"s,
then mothera is treated as Hero not Monster.
This is not the behavior described in the documentation:
https://docs.raku.org/language/glossary#index-entry-Multi-Dispatch
Multi-dispatch§
The process of picking a candidate for calling of a set of
methods or subs that come by the same name but with different
arguments. The most narrow candidate wins. In case of an
ambiguity, a routine with is default trait will be chosen if
one exists, otherwise an exception is thrown.
Re: Different behavior for strings and strings in variables with multi-dispatch using a subset
> You overlooked a mistype. The subset expects "wuhn", you pass "whun" instead.
> Guess, the subset is wrong about it. :)
Yes indeed, that seems to be all it is. Thanks much.
And maybe I'll go back to monster names in my demos.
On 9/22/21, Vadim Belman wrote:
>
> You overlooked a mistype. The subset expects "wuhn", you pass "whun"
> instead. Guess, the subset is wrong about it. :)
>
> Best regards,
> Vadim Belman
>
>> On Sep 22, 2021, at 8:39 PM, Joseph Brenner wrote:
>>
>> In this code I'm using multi-dispatch with a subset type that
>> makes string values special: "wuhn", "tew" and "thuree".
>>
>>use Test;
>>
>>multi sub whats_my_type (Str $item) {
>>return "This is a Str: $item";
>>}
>>
>>subset GoofyNum of Str where { $_ eq any( 'wuhn', 'tew', 'thuree' ) };
>>multi sub whats_my_type (GoofyNum $item) {
>>return "This is a GoofyNum string: $item";
>>}
>>
>>{
>>my ($ret, $arg);
>>$ret = whats_my_type('two');
>>like $ret, /<< Str >>/, "quoted string argument of 'two' is Str";
>>
>>$ret = whats_my_type('tew');
>>like $ret, /<< GoofyNum >>/, "quoted string argument of
>> 'wuhn' is 'goofy'";
>>
>>$arg = "one";
>>$ret = whats_my_type( $arg );
>>like $ret, /<< Str >>/, "string in var argument of '$arg' is Str";
>>
>>$arg = "whun";
>>$ret = whats_my_type( $arg );
>>like $ret, /<< GoofyNum >>/, "string in var argument of 'wuhn'
>> is 'goofy'";
>>}
>>
>>
>> I would think all four of these tests should pass, instead I see
>> the last one failing: for some reason there's a difference in the
>> case of a simple quoted string, and a string inside a variable.
>>
>> Any comments?
>>
>>
>> raku --version
>> Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
>> Implementing the 퐑퐚퐤퐮™ programming language v6.d.
>> Built on MoarVM version 2020.10.
>>
>> uname -a
>> Linux fandango 4.9.0-8-686 #1 SMP Debian 4.9.144-3 (2019-02-02) i686
>> GNU/Linux
>>
>
>
The SF Perl Raku Study Group, 09/26 at 1pm PDT
E.K. Rand, "Founders of the Middle Ages" (1928): You begin to remove accretions, you peel and peel, till nothing is left-- nothing but the knife, the own peculiar knife, of the peeler. The Raku Study Group September 26, 2021 1pm in California, 8pm in the UK Zoom meeting link: https://us02web.zoom.us/j/84405232275?pwd=cFNnaXFQODJIdUYwV2pLT3kzMlIwUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/280953141/
Different behavior for strings and strings in variables with multi-dispatch using a subset
In this code I'm using multi-dispatch with a subset type that
makes string values special: "wuhn", "tew" and "thuree".
use Test;
multi sub whats_my_type (Str $item) {
return "This is a Str: $item";
}
subset GoofyNum of Str where { $_ eq any( 'wuhn', 'tew', 'thuree' ) };
multi sub whats_my_type (GoofyNum $item) {
return "This is a GoofyNum string: $item";
}
{
my ($ret, $arg);
$ret = whats_my_type('two');
like $ret, /<< Str >>/, "quoted string argument of 'two' is Str";
$ret = whats_my_type('tew');
like $ret, /<< GoofyNum >>/, "quoted string argument of
'wuhn' is 'goofy'";
$arg = "one";
$ret = whats_my_type( $arg );
like $ret, /<< Str >>/, "string in var argument of '$arg' is Str";
$arg = "whun";
$ret = whats_my_type( $arg );
like $ret, /<< GoofyNum >>/, "string in var argument of 'wuhn'
is 'goofy'";
}
I would think all four of these tests should pass, instead I see
the last one failing: for some reason there's a difference in the
case of a simple quoted string, and a string inside a variable.
Any comments?
raku --version
Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
Implementing the 퐑퐚퐤퐮™ programming language v6.d.
Built on MoarVM version 2020.10.
uname -a
Linux fandango 4.9.0-8-686 #1 SMP Debian 4.9.144-3 (2019-02-02) i686 GNU/Linux
The SF Perl Raku Study Group, 09/12 at 1pm PDT
Sun Ra "Enlightenment" (1956): "The Sound of Joy is Enlightenment Space, Fire, Truth is Enlightenment ... Strange Mathematics, Rhythmic Equations" The Raku Study Group September 12, 2021 1pm in California, 8pm in the UK Zoom meeting link: https://us02web.zoom.us/j/89310613568?pwd=SUVEUXNVbSsxdXNjL2NIREc0M2I0UT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/280656796/
The SF Perl Raku Study Group, 08/29 at 1pm PDT
Gil Scott-Heron "I'm New Here" (2010): No matter how far wrong we've gone We can always turn around ... Turn around, turn around, turn around And you may come full circle And be new here again https://www.youtube.com/watch?v=eV_astp3BjM The Raku Study Group Sunday August 29 1pm in California, 8pm in the UK Zoom meeting link: https://us02web.zoom.us/j/84422463875?pwd=OW1PU2pKeGNwWVRreURjdU5oMlVuUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/280349043/
Re: intermixed types and resulting types
References: In-Reply-To: toddandma...@zoho.com wrote: > If you go to https://docs.raku.org/ and look up your variable, > scroll down and look for "type graph", it will tell you what > your variable is a member of. Yes, that's right. For any particular case, you could check the type graphs and get an idea what they have in common. In particular, the roles involved (indicated in Blue) are often critical if you're trying to spot similar capabilties (which I'm calling vaguely "compatibility" for now). But then, in a case like this one, how would you know in advance that it would work, without Just Trying It: my @monsters = < godzilla grendel wormface blob >; my $cool_monsters = < godzilla ghidra mothera >.Set; say @monsters.WHAT; # (Array) say $cool_monsters.WHAT; # (Set) my $just_monsters = @monsters (-) $cool_monsters; say $just_monsters; # Set(blob grendel wormface) A set difference operation seems to know what to do with arrays, without any explicit conversion steps. I don't think you can get that just from studying the type graphs Anyway, I'm wondering if there's some sort of way of getting a general answer to the question of what works with what. > Any any one that acts like Raku's OOP is h-a-r-d if pulling > your strings. I stink at programming and I learned it, despite > some of the insults I got thrown at me (not from this quarter, > thank goodness) By the way, I have to say I appreciate your stick-to-itiveness. It's not at all a bad thing to have some beginners around who are willing to be loud about it-- it's not supposed to be an experts club.
^mro_unhidden
Given and example like this:
class A {}
class B is A {}
class D is B {}
say D.^parents(); # ((B) (A))
say D.^parents( :all ); # ((B) (A) (Any) (Mu))
So, I conclude that Any and Mu are "hidden" as far as ^parents is concerned.
According to the documentation, ^mro_unhidden does this:
"Returns a list of types in method resolution order, excluding
those that are marked with is hidden."
And yet, what I see is:
say D.^mro_unhidden; # ((D) (B) (A) (Any) (Mu))
So why does this include Any/Mu?
A somewhat related question: How do you check whether a trait is set
on something?
Can you get a list of all traits?
raku --version
Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
Implementing the 퐑퐚퐤퐮™ programming language v6.d.
Built on MoarVM version 2020.10.
intermixed types and resulting types
There are some object types that are "compatible" in certain ways, for example: o You can do arithmetic operations on any Numeric types, a Rat minus and Int just works (and gives you a Rat). o You can do set operations on any of the QuantHash types (and some other things, like Arrays), so you can take the set difference of a Mix and a Bag (and you'll get a Mix). How would you know what types are compatible for a particular operation? Is there a way to know what the resulting type is going to be? Is there some sort of rule about using the least-specific possible type?
The SF Perl Raku Study Group, 08/15 at 1pm PDT
Kim Stanley Robinson, "Ministry of the Future" (2020): "Ideology, n. An imaginary relationship to a real situation. In common usage, what the other person has, especially when systematically distorting the facts. "But it seems to us that an ideology is a necessary feature of cognition, and if anyone were to lack one, which we doubt, they would be badly disabled." The Raku Study Group August 15, 2021, Sunday 1pm in California, 8pm in the UK Zoom meeting link: https://us02web.zoom.us/j/83713411144?pwd=bHJCQ3UzZjA3ejlOY1RSOU5qaXJQUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/280061657/
Re: callbacks with placeholder vars
There's this much: https://docs.raku.org/language/variables#index-entry-$$CIRCUMFLEX_ACCENT > If you have self-declared a parameter using $^a once, you may refer to it > using only $a thereafter. But it doesn't go anywhere near far enough. You *had better* to refer to it as $a or you'll get some very weird behavior, though only under some circumstances.
Re: callbacks with placeholder vars
Okay, so my central confusion here has to do with not
understanding that the caret gets used *only once* in
a construct like this:
my $cb = {
do if ($^a eq $^b) {
"$a";
} else {
"$a & $b";
}
};
say $cb( 'a', 'b' );
After $^a is used, then $a is declared, and you use that form.
So, if you think of $^a as just a funny variable name, you'll get
tripped up in the ways I was, because if you use it again in
the sub-blocks of the if/else, it thinks you're trying to tell
it something about the calling signature for the sub-blocks.
You can however use the "$^a" form repeatedly if you're *not*
using any sub-blocks though, as in the ternary form I was playing
with.
I don't think this usage is very well described anywhere, though
you can argue you should just Get It if you understand that the
caret is a twigil.
And I still think the messaging here is more than a little LTA.
callbacks with placeholder vars
Here's a simple use of a callback that just works:
my $cb = {
"$^a & $^b";
};
say $cb('a', 'b'); # a & b
Just as an aside, it's interesting that this would be an error:
say $cb('a', 'b', 'c');
# Too many positionals passed; expected 2 arguments but got 3
The number of placeholder vars inside the block gives it an
implicit arity, despite the absence of any explicit signature.
You can of course do more complex things, e.g. using this ternary conditional:
my $cb = {
($^a eq $^b) ?? "$^a" !! "$^a & $^b";
};
say $cb( 'a', 'b' ); # a & b
say $cb( 'c', 'c' ); # c
However, doing the same thing with an if/else construct doesn't work.
It generates a pretty baffling error message:
my $cb = {
do if ($^a eq $^b) {
"$^a";
} else { # line 48
"$^a & $^b";
}
};
say $cb( 'a', 'b' );
# Too few positionals passed; expected 2 arguments but got 1
# in code at
/home/doom/End/Cave/Perl6/bin/callback_placeholder_vars_and_if_else-out.raku
line 48
# in block at
/home/doom/End/Cave/Perl6/bin/callback_placeholder_vars_and_if_else-out.raku
line 46
# in block at
/home/doom/End/Cave/Perl6/bin/callback_placeholder_vars_and_if_else-out.raku
line 5
I theorize that Raku is treating the blocks of the if/else much like
the surrounding block,
and using a count of the placeholder vars to get an implicit arity for
the "else" block--
(why it's just getting one thing passed and not two, that I don't get).
So, what if we move the use of the placeholder vars outside of the
if/else? A: yet another baffling error
my $cb = {
my $a = $^a;
my $b = $^b;
do if ($a eq $b) {
"$a";
} else {
"$a & $b";
}
};
say $cb( 'a', 'b' );
# ===SORRY!=== Error while compiling
/home/doom/End/Cave/Perl6/bin/callback_placeholder_vars_and_if_else-out.raku
# Redeclaration of symbol '$^a' as a placeholder parameter.
# at
/home/doom/End/Cave/Perl6/bin/callback_placeholder_vars_and_if_else-out.raku:85
# --> my $a = $^a⏏;
Flailing around a bit, I concluded there was something strange
going on with the variable name $a, e.g. *this* works:
my $cb = sub {
my $alpha = $^a;
my $beta = $^b;
return do if ($alpha eq $beta) {
"$a";
} else {
"$a & $b";
}
};
say $cb( 'a', 'b' ); # a & b
It is of course, also possible to use an explicit sub-signature
instead (this at least, just works):
my $cb = sub ($a, $b) {
my $result =
do if ($a eq $b) {
"$a";
} else {
"$a & $b";
};
return $result;
};
say $cb( 'a', 'b' ); # a & b
say $cb( 'e', 'e' ); # e
I'm using:
raku --version
Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
Implementing the 퐑퐚퐤퐮™ programming language v6.d.
Built on MoarVM version 2020.10.
The SF Perl Raku Study Group, 07/24, SATURDAY at 1pm PDT
Paul Krugman, "Peddling Prosperity" (1994): "... there is a circularity: the network of support and reinforcement that makes a technology fully productive is both a cause and a result of that technology's widespread use. So a new technology, no matter how marvelous, may have only superficial effects for decades, then flower as it finally reaches critical mass." The Raku Study Group July 24, 2021, SATURDAY, 1pm in California, 8pm in the UK Zoom meeting link: https://us02web.zoom.us/j/89219572492?pwd=M1ZEMU5uRWtiNCtXZnU3dnp5OW1DUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/279639325/ Note: this week we're bumping up the meeting from our usual Sunday session to Saturday, July 24th. And don't forget the Raku Conference coming up on August 6-8, 2021 https://conf.raku.org/
Re: use lib and locations in a variable
Elizabeth Mattijsen wrote:
>> Joseph Brenner wrote:
>> I find that while this works:
>>
>>use lib $*PROGRAM.parent.add('../lib');
>>
>> This doesn't work:
>>
>>my $lib_loc = $*PROGRAM.parent.add('../lib');
>>use lib "$lib_loc";
>>
>> I get a compile time error
>>
>>Use of uninitialized value $lib_loc of type Any in string context.
> This can be easily fixed in Raku: the BEGIN statement can also be used as a
> prefix:
>
> BEGIN my $lib_loc = $*PROGRAM.parent.add('../lib');
> use lib "$lib_loc";
Yes that's a good fix. Bruce Gray points out "constant" works also:
constant $lib_loc = $*PROGRAM.parent.add('../lib');
> One note: I'm a bit surprised of the mixture of OS dependent (../) and OS
> independent (.parent) directory walking. I guess you meant:
>
> $*PROGRAM.parent.parent.add("lib")
I'll take it under advisement that there might be some system out
there that can't deal with the unixism ".." (though my experience
is those are getting increasingly rare).
I might start doing something like this:
$*PROGRAM.parent(2).add("lib")
>> I thought that this would fix the problem, but I see the same
>> compile time error with it:
>>
>>BEGIN {
>> my $lib_loc = $*PROGRAM.parent.add('../lib');
>> use lib "$lib_loc";
>>}
>
> Inside the BEGIN block, it's just the same: the variable is defined, but not
> initialized yet when the "use lib" is executed at compile time *inside* the
> BEGIN block.
Right, got it. One of the reasons I was confused is I'd also
tried this:
BEGIN {
my $lib_loc = $*PROGRAM.parent.add('../lib');
}
use lib "$lib_loc";
But there the trouble is the scope of the block. This works:
my $lib_loc;
BEGIN {
$lib_loc = $*PROGRAM.parent.add('../lib');
}
use lib "$lib_loc";
As does the approach you suggest:
BEGIN my $lib_loc = $*PROGRAM.parent.add('../lib');
> ... BEGIN as a prefix, so that it shares its scope with its
> surrounding scope.
And that's definitely a key advantage
> This is not different from Perl, BTW.
Yes, and as I remember it, I've gone through a similar set of
mistakes with Perl.
Re: use lib and locations in a variable
Just to clarify my use case a bit:
Joseph Brenner wrote:
> I want my test files to be able to find the modules they're testing
> just using their relative locations, given the usual layout of "lib"
> and "t" locations in parallel inside the project directory.
That's like so:
project
|
--
||
lib t
There are *.t files (raku scripts) in the "t" location, and they're
intended to exercise the *.rakumod files located under the "lib"
location. Unless you've got every "lib" in every project on your
system included in your PERL6LIB directory, you're going to need to Do
Something if you want the *.t files to be able to find the modules
under development.
That's what something like this does:
> use lib $*PROGRAM.parent.add('../lib');
"use lib" adds that path to the locations raku will search for modules.
Here the path is determined starting with the path to the currently
running script:
$*PROGRAM.parent
>From there we go up one more level, then look down into the lib location.
I gather that many people would change directories into the "t"
directory before running the tests there, but myself I like to just
use full paths to the tests, so my current directory might be set to
any where. So starting at the "." doesn't really work for me.
use lib and locations in a variable
I want my test files to be able to find the modules they're testing
just using their relative locations, given the usual layout of "lib"
and "t" locations in parallel inside the project directory.
I find that while this works:
use lib $*PROGRAM.parent.add('../lib');
This doesn't work:
my $lib_loc = $*PROGRAM.parent.add('../lib');
use lib "$lib_loc";
I get a compile time error
Use of uninitialized value $lib_loc of type Any in string context.
...
Repository specification can not be an empty string. Did you mean
'use lib "."' ?
I thought that this would fix the problem, but I see the same
compile time error with it:
BEGIN {
my $lib_loc = $*PROGRAM.parent.add('../lib');
use lib "$lib_loc";
}
Does that make sense to anyone? It feels like a bug to me.
The SF Perl Raku Study Group, 07/11 at 1pm PDT
Heather McGhee, "The Sum of Us" (2021): "I fell in love with the idea that information, in the right hands, was power." The Raku Study Group July 11th, 2021 1pm in California, 8pm in the UK Zoom meeting link: https://us02web.zoom.us/j/84275775889?pwd=SXd6VW96bk1oZS85K0JOeWNSZU5zZz09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/279354456/
The SF Perl Raku Study Group, 06/20 at 1pm PDT
Edgar Rice Burroughs, "Tarzan of the Apes" (1914) Ch 7, "The Light of Knowledge": His little face was tense in study, for he had partially grasped, in a hazy, nebulous way, the rudiments of a thought which was destined to prove the key and the solution to the puzzling problem of the strange little bugs. The Raku Study Group June 20, 2021 1pm in California, 8pm in the UK Zoom meeting link: https://us02web.zoom.us/j/87429079850?pwd=VENuRi9YbjAzZ1paRmtoVW9iaWtvUT09 Passcode: 4RakuRoll RSVPs are useful, though not needed: https://www.meetup.com/San-Francisco-Perl/events/278735631/
Re: [sf-perl] Perl/Raku "Conference in the Clouds" (and the Raku Study Group postponed)
Sorry, I meant June 20th. On 6/10/21, Earl Ruby wrote: > May 20th of what year? > > On Sun, Jun 6, 2021 at 2:34 PM Joseph Brenner wrote: > >> As I expect most of you have heard, there's another >> perl/raku "conference in the clouds" coming up this week, >> starting on Tuesday. The schedule is online: >> >> https://perlconference.us/tprc-2021-cloud/schedule/ >> >> Tickets for this one are just $10: >> >> >> https://www.eventbrite.com/e/conference-in-the-cloud-2021-a-perl-raku-conference-tickets-149184602161 >> >> And I've decided to postpone the next Raku Study Group meeting to >> May 20th: doing one right after this conference would be a >> little too much, I'd think. >> ___ >> SanFrancisco-pm mailing list >> sanfrancisco...@pm.org >> https://mail.pm.org/mailman/listinfo/sanfrancisco-pm >> > > > -- > Earl Ruby > http://earlruby.org/ > http://www.linkedin.com/in/earlruby > https://twitter.com/earlruby >
