Parrot 4.7.0 "Hispaniolan" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 4 September 2012.
00:12 benabik joined 00:30 kid51 joined 01:32 benabik joined 01:44 MikeFair joined 02:03 mvorl joined
MikeFair Hello there #parrot 02:04
dalek rtcl-nqp/nqp2: 868ef43 | coke++ | src/Partcl/commands/time.pm:
fixup [time]
 02:49
rtcl-nqp/nqp2: 4c10dd8 | coke++ | src/Partcl/commands/info.pm:
fixup [info]
rtcl-nqp/nqp2: 488d13d | coke++ | src/Partcl/commands/unset.pm:
fixup [unset]
rtcl-nqp/nqp2: 0b1e72a | coke++ | src/Partcl/commands/upvar.pm:
fixup [upvar]
rtcl-nqp/nqp2: b0ae2f9 | coke++ | src/Partcl/commands/proc.pm:
fixup [proc]
rtcl-nqp/nqp2: f2aa12c | coke++ | src/Partcl/commands/expr.pm:
fixup [expr]
rtcl-nqp/nqp2: b188cf2 | coke++ | src/Partcl/commands/array.pm:
fixup [array]
05:31 contingencyplan joined 06:00 mvorl joined 08:19 Psyche^ joined 09:52 mvorl joined 11:37 whiteknight joined 11:40 JimmyZ joined
dalek p: b4dec6c | jnthn++ | src/PASTRegex.pir:
Stop exporting the dummy PAST package.
 11:54
p: e19b5fd | jnthn++ | src/stage0/ (9 files):
Update stage0 to eliminate PAST package cross-refs.
p: 1ff9f02 | jnthn++ | src/PASTRegex.pir:
Further gut the PAST inclusion code.
whiteknight good morning, #parrot 12:00
12:08 JimmyZ joined
dalek p: 718a3fc | jnthn++ | src/ (5 files):
Eliminate a bunch more PAST references.
 12:17
kudo/nom: 0ead9e4 | jnthn++ | tools/build/NQP_REVISION:
Bump to an NQP that doesn't load/import PAST.
 12:18
12:56 kid51 joined 13:38 PacoAir joined 14:18 Khisanth joined 14:58 JimmyZ joined 17:48 MikeFair joined
MikeFair Howdy #parrot! :) 17:57
nopaste "Allison" at 202.71.99.222 pasted "I'm from England <a href=" purchasekamagra.devhub.com/ ">Purchase Kamagra </a> from a manual claim. <a href=" cheapkamagra.devhub.com/ ">Cheap K" (6 lines) at nopaste.snit.ch/164365 18:14
allison wow, I wish they'd stop using my name for IRC spam :)
pastebot needs captcha 18:16
whiteknight hello MikeFair 18:28
hello allison
18:37 benabik joined
MikeFair whiteknight: Hi there 18:39
allison hi whiteknight :) 18:41
MikeFair allison / whiteknight: I had some ideas /questions to run by you guys 18:53
I've got this idea to make a "program" act like a network of interconnected nodes, basically I think it's the same thing that erlang is doing, but I don't know erlang and haven't studied it 18:54
I've been looking into ZeroMQ / Crossroads I/O and one of the things they've got is idea of a topology, which is linked of networked "contexts" where a context is usually associated with an application or thread 18:55
Then I was thinking / looking at Namespaces in programming languages, like the one I'm thinking of and parrot
and what struck me was the similarities between namespaces in programming languages and network routing 18:56
So what I started considering was constructing a program where each "namespace" got a 24-bit identifier, and every "name" within that namespace also got a 24-bit identifier (aka essentially creating a graph of 24-bit address sapces) 18:57
I selected 24-bits because that lines up with the register size of the NVidia GPU cards 18:58
Coincidentally, putting the two 24-bit identifiers together (Namespace::identifier) == one single 48-bit identifier == the same length as an ethernet MAC address 18:59
So a function call would come from some context (the 24-bit id of the function, plus the 24-bit id of the "context"/"namespace" that function exists in), and go to some function in another(or the same namespace) (again a 24-bit namespace id + 24-bit function id) 19:02
So given a dedicated network consisting of many parrot instances - the instances could share their 24-bit ids with each other, publish the 24-bit ids of the identifiers they make public, and create a kind of distributed networking platform 19:04
This could be easily optimized in the case everything was on the same machine, but the model works as if all the namespaces exist on different machines 19:05
19:05 contingencyplan joined
MikeFair By putting the data of an execution context in the body of the ethernet frame, it could be sent across the wire to another parrot instance. 19:06
Lastly, as all the parrot instances can see each other, and every namespace in the application has its own 24-bit id to identify it, then every parrot instance should be able to get at all the namespaces of all the parrot instances in that "topology" 19:08
Instead of the Parrot VM receiving a block of memory to execute, it would receive a queue of instructions
those instructions would operate on the data frame sent by the caller (or something like that, as there's clearly a separation between code being dequeued and data as an array/namespace block) 19:10
What makes using ZeroMQ /Crossroads I/O useful here is that they've got a zero-copy algorithm for sending messages through their queues intra-process, can use PIPES for interprocess, and sockets for intermachine data, and they present the same API regardless of what mechanism is used 19:14
Gotta go, family is going out to lunch, bbl, and BTW: 19:17
Thanks for parrot!!! It's inspiring! :)
19:18 mvorl joined
tadzik :) 19:19
19:23 lucian joined 19:33 schmooster joined
allison MikeFair: It sounds like a very interesting project. 20:02
MikeFair: I recently worked with ZeroMQ on a smart home project, where the "brain" consisted of a collection of networked nodes communicating 20:03
MikeFair: I was impressed at how lightweight it is, it would work quite well with Parrot
MikeFair: and, it already has C bindings, so would link in easily 20:04
MikeFair allison: great to hear 20:08
allison: I'm glad you've already got some experience with it too! It's hard for me to express how to ppl just how lightweight it is
allison: And the one thing they haven't really worked out is creating their own namespace framework 20:09
allison MikeFair: yeah, they kind of have hacky namespaces in messaging by matching on the first few characters 20:12
MikeFair allison: It's pretty clear to me that having a namespace discovery system all its own that focuses on the topologies of the system rather than the underlying DNS/IP network would help it along quite nicely :)
allison but nothing structured
MikeFair allison: Which is really more of a "topic" kind of concept
:)
allison yeah, sounds like a fun project :) 20:13
MikeFair allison: So the thing I saw was that a DNS domain would publish a series of "topologies" (aka high level services), you'd connect to port 1 (which has an actual IETF standards service for i) which is all about connecting to a named service
allison: port 1 would allow you to initiate the "DOMAIN" command, where you could enter a DNS domain name, and assuming you got past whatever IAAA that domain required then you'd be able to list topologies and connect to them 20:14
allison: At that point you'd likely be talking to parrot and grammars 20:15
:)
That's the kind of vision I've got going for it 20:16
Then the tie in to the GPU is that the way OpenCL/CUDA work is you actually send your code to the GPU to be compiled and executed, which is kind of like what I see Parrot doing
So the concept of running a Parrot VM on each processor in the GPU seems to work out well, at least in concept 20:17
allison MikeFair: kind of like distributed interpreting 20:18
MikeFair I keep trying to imagine how incredibly awesome a GPU based regex parsing engine would be:)
allison: That's exactly it
allison MikeFair: security concerns on an open network, but behind a firewall would be reasonable 20:19
MikeFair allison: I'm thinking of running it over XMPP, and then private networks behind firewalls
allison and, machines could have some form of caching, so code isn't resend constantly
or even remote loading, for common libraries 20:20
MikeFair allison: Exactly! Are you familiar with the nomachine stuff for the X server protocl?
allison: that's more like what I was thinking, actually a distributed version control system for libraries at some point
allison only the general principles, I haven't gotten into the code
MikeFair allison: So the thing they do is register the function, its signature, and each time its called, they cache the variables used 20:21
allison: That 'instance' gets an ID, the id says 'these variables change each time I call and these values are static'
allison: I think technically they predetermine the registered functions 20:22
allison: So its like one step below MMD
allison: In addition to dispatching on types, they can dispatch on 'differing values'
allison ah, interesting 20:23
MikeFair allison: So they can just send 'execute version X of method Y and here's the few parts you don't have'
allison: They are capitalizing on the fact that most function calls are called with most of the same values most of time (like the same bitmap pointer for the background for instance) 20:24
allison: (and the only thing they need to send are the X,Y coordinates to draw it at)
allison yeah, it makes a lot of sense for X 20:25
MikeFair allison: It occurs to me that a lot of more complicated programs could benefit generically from such a feature, especialy in a distributed intrepretter
:)
allison I can think of a lot of cloud services that get called with the same values over and over again 20:26
MikeFair so Parrot, with its ambitious goals of ruling them all becomes the obvious choice for this concept to get baked into :)
allison and, only a few variants each time
MikeFair allison: yeah agreed :) and if each function was its own 24-bit namespace, then you could register 16.7 million variants before even needing to think about it :) 20:27
allison so, do you think it's more important to support sending the uncompiled source "over the wire"? or to support the function calling interface 20:28
?
I've been working a lot lately with JSON RPC-based services
MikeFair allison: I was thinking the source code would generate an MD5SUM or a SHA1 and that would get registered with the network
allison: Actually I take that back, that happens, but that hash key gets bound with an "interface" 20:29
allison so all machines would get identical copies of the source code?
MikeFair allison: they could, what would happen is the interface (function signature) has one key, and that gets bound to another function key
allison: So the service provider side says "I'm publishing these signatures" and then saying "and they are executed/bound to these functions" 20:30
allison: If a node didn't have that function implementation it could ask for it 20:31
allison: I'm thinking of multiple implementations for generating a SHA1 key as an example
allison: Let's say one does it wrong
allison in a distributed fashion, like DNS propagation?
MikeFair allison: Or just different from the others
allison (so, it could ask its neighbor, not just a central service?)
MikeFair allison: Yeah, but its more tightly knit, yes, the central service 20:32
allison: "You have a 24-bit address space in which to register your neighbor namespaces"
allison: "they'll tell you their ID and you tell them yours
allison: Within a one hop mesh, all addresses are unique
allison: Each of them, can then announce/publicize their distinct entities within their 24-bit space 20:33
allison: The combination of 24-bit namespace and 24-bit id = one 48-bit "pointer" to something in the mesh 20:34
allison: Sometimes, a namespace will take up one its slots to announce something that is contained in one of its other neighbors (that's not part of the mesh) 20:35
allison: So each node can talk about 16.7 million things, some of the things are local to it, and some of the things are about its neighbors things
So namespace packages A::B::C::D would suck 'D' into my local space 20:36
but I'd send the request through A when I wanted to atlk to it 20:37
I haven't exactly worked that part out yet
but that's something that you guys have to work with all the time so I figured I learn what it takes to do that here
I think what happens is I make 'D' one of my 16.7 million nodes that my namespace can connect to 20:38
allison: hehe - I actually mispoke earlier about the central service 20:39
allison: it's not the central service model, it's the neighbor query model
allison yes, the neighbor model is more powerful in a mesh
central service is more fragile, single point of failure 20:40
MikeFair allison: though I keep envisioning that the root node might use DNS to discover other meshes so I can talk to things that aren't in my same administrative domain
moritz though easier to guard against races (the central model)
MikeFair moritz: My plan, I think, is to force agreement between two nodes 20:41
moritz: So each "link" can only talk about 16.7 million things
allison MikeFair: you might look at PXE booting as a model
MikeFair moritz: Node A and Node B have to agree that X refers to the same thing on both sides
allison MikeFair: (of code executed via discovery service) 20:42
MikeFair however nothing prevents either of them from translating X into W,Y, and Z when they tell other nodes about it
So the guy in the middle B, might call it X when talking to A, and call it Y when talking to C, and call it Z when talking D 20:43
and the node keep tracks of the mapping like a big NAT table
allison: I'll look at that, I haven't looked at PXE before (though I've used it occasionally) 20:44
I'm kind of lost on the best place to begin though. I ultimately plan on having my own version of an xTalk language, so I figured I start by trying my hand at implementing that (which would get me introduced to the Parrot architecture and world) and then go from there 20:47
By talking about it with other folks I hope to learn what this takes and maybe inspire a few people with some ideas that can make my life easier as they code some of the framework to make something like this possible in what they're already doing :) 20:48
Or at least figure out who to talk to about certain pieces of the code :)
MikeFair gets called away to take his daughter for soccer pictures. :) 20:49
allison / moritz: thanks for the feedback! I'll be back later. :)
allison MikeFair: enjoy the soccer! 20:50
MikeFair: (and you might start with a simple winxed library, as a proof of concept) 20:51
21:05 alvis joined
MikeFair is back. :) 22:13
allison: We enjoyed ourselves, the girls took a beautiful picture, and it should turn out nice! :) 22:15
allison: I was thinking about being brain dead about it initially and adding a ZMQ socket to my base PMC object 22:17
allison: I'm assuming everything I'd ever want to talk to will be some derivation of a PMC somehow
allison: "Packages" would get a new context and bind a device or socket of some kind, then PMCs within that namespace would open up a socket to the namespace 22:19
using PAIR
allison: Then I'd jsut need to get namespaces to PAIR with each other
along the way I'll likely realize how wrong that design is and then see what it really needs to be 22:20
I'm expecting some combination of PUB/SUB REQ/REP and REP/REQ
Perhaps certain objects acting a broker devices for other objects
This is the kind of thing I think SmallTalk, Erlang, and probably a lot of ZMQ / CrossroadsI/O guys already have figured out so i'm expecting to do a lot of copying their patterns instead of designing totally new unless I think I really have to 22:22
Combined with a few thoughts from folks like you, whiteknight, moritz, sorear, and the others around here and I think it could become something pretty cool -- oncely it becomes something sanely comprehensible, that works, and is a good performer. :) 22:24
allison MikeFair: yes, in Parrot the objects are PMCs, the functions are PMCs, pretty much everything you work with from a high-level language is a PMC
MikeFair: with int, float, and strings as lower-level primitives, but still usually PMCs in the HLLs (because each language has extra behaviors, even for strings and numbers) 22:25
MikeFair allison: Right so that follows along with what I was thinking, give PMCs a 24-bit unique id, that's unique within whatever container it's a part of
allison: Right, I was thinking I wouldn't give the primitives a unique id, the get an address within their containing PMC (the PMC creating a 24-bit named register address space) 22:27
sorear me?!
MikeFair allison: So in my world, Parrot would get 16.7 million registers per PMC
allison MikeFair: aye, and best to construct your own id scheme, rather than using implementation details inside the VM
MikeFair: that should last us a while :) 22:28
MikeFair sorear: yeah you because you're doing the .Net implementation of Perl6 and were thinking about the "network namespace of packages" rather than the single global flat namespace, you've already got ideas I can use to make this thing work. :)
allison: Yeah I kind of figured 24-bit per PMC would be enough satisfy people's concerns and yet still be a practical finite limitation that mapped well onto hardware (especially mobile and GPU hardware), and with the builtin 22:29
nesting / NATing of addresses I've got planned it should scale really well 22:30
allison: I also wanted my own addressing scheme so that underlying architecture implementations could use address translation maps to get to the real in-memory address on whatever architecture that was 22:32
22:33 benabik joined
MikeFair allison: I exptect eventual optimizations to ditch the 24-bit scheme whenever talking internally within the same process or even the same machine - and only enforce when going 'outside the VM' 22:33
but that's in the "we'll get there" category atm let's make 'as designed ' work first before "cheating" :) 22:34
allison: So what winxed library did you see would be good? 22:35
allison: I was thinking I'm doing my language 'Safire' which will eventually get classes
allison: At that point, I'll start working with the PMCs 22:36
allison MikeFair: well, I figured starting with winxed+zmq you could get a full model network going
MikeFair: faster for experimenting 22:37
MikeFair allison: agreed, but I had a hard time thinking about "but what would it talk about"
allison: So I was thinking if I created a "Root" namespace that two Parrot VMS could share
allison MikeFair: then move a level deeper as you're comfortable you're heading in the right direction
MikeFair allison: Then creating a package and classes on one node would just "show up" in the other, likely needing to transmit the PBC in the process 22:38
allison MikeFair: on which libraries, you've got network discovery to work on, and compiling code over the wire, and remote function calls
MikeFair: as well as the ZMQ interface 22:39
(wrapping ZMQ in an object is nicer than working directly with the C bindings)
MikeFair allison: exactly, I was thinking that target was small enough to be comprehensible, but big enough to still force all the core issues to the fore
allison: Well I was thinking a PMC would basically become a ZMQ 'queue' device 22:40
allison: and all the magic would 'just happen' inside the PMC implementation
allison: it would figure out what was a remote call and what wasn't, etc 22:41
allison MikeFair: call me greedy, I was hoping for a general ZMQ library that your code uses :)
MikeFair allison: and that's where I'd likely be spending all my time
allison: How more general could it be if every PMC "WAS" a ZMQ library?! ;) 22:42
allison MikeFair: but sure, it could be purely internal
MikeFair allison: but perhaps I'm missing something
allison: I was thinking "ZMQ comes for free when you use Parrot"
allison: And automatically builds a peer2peer mesh kind of like erlang does 22:43
allison MikeFair: follow your gut, it can always be refactored later 22:44
MikeFair allison: sounds good. btw, I like greedy! :)
allison: I plan on using the Microsoft SQL Server Service Broker as something I consider a good mesaging model 22:45
allison: Whereas ZMQ puts the messaging rules in the socket type, the Service Broker uses a second construct called a "contract" and so when you open a "Conversation" to another node, the "conversation" follows the "Contract" but can reuse the channel/queue 22:46
allison MikeFair: I haven't really looked into it, so can't offer much perspective.
MikeFair allison: Where the channel/queue represents a link
allison: I like to think about it from the perspective "Of what is the code I want to end up writing to actually using this thing from my HLL" 22:47
allison: And make the 'top layer' and make whatever is beneath that do anything required to make my interface 'easy' :)
it's like test driven development, so anything you can think of that would make your programming life easier from the perspective of "using" the library, please let me know/keep me in mind/send me some notes 22:48
allison MikeFair: it's a good design methodology 22:49
MikeFair And that goes for everyone else too
The key thing is to actually make it useful and transparent
allison helps avoid the problem of "great idea with an unusable implementation"
MikeFair (or at least as transparent as is useful to still leave people with the controls need) 22:50
allison: totally agreed, and it's not like I'm reinventing or pioneering some new field of computer science here, I think most of these issues have already been worked out in those other systems and I just copy their work and integate those patterns 22:51
like PXE, ZeroConf, erlang, CUDA/OpenCL, DHCP/DNS/ZeroConf/et al, http, json, rest --- all that stuff has already proven most of the core concepts -- so all that's left is how do we make all that work for us :) 22:52
allison MikeFair: it's a time honored tradition :)
MikeFair: most innovation really is a slight edge forward on what went before 22:53
MikeFair I'm with you there
sorear don't forget. 'If I have seen further than others it is because I stand on the shoulders of giants.'
MikeFair exactly! 22:54
As complex as it might sound at first, I'm thinking you take the OpenCL/CUDA concepts and merge them with the Erlang concepts and you get a good distributed messaging/computing platform 22:56
You use Parrot VM and PIR in place of the OpenCL/CUDA code
You let ZeroMQ do its thing as a messaging backbone within and between the packges/namespaces inside the Parrot VM 22:58
and let Parrot PMCs take care of the naming/DNS type lookup, resolution, and execution
Lastly, and this is the 'innovative' part, you make it easy to bind the values between PMCs together throughout the distributed system 22:59
well actually I just ripped that off from .Net -- well more specifically Micosoft's classes
And their ideas behind a "binding context" and "currency manager" 23:01
I think if Parrot had the concept of "entagled" PMCs, where you could use a function to do define the relationship of the entaglement, that could be really powerful 23:02
When the programmer is able to express the concept of "all these PMCs are part of one system and their values are related in this way" it becomes "something new" beyond "the sum of its parts" 23:08
in concept anyway
:)
MikeFair goes back to trying get his "say" statement to work without crashing the interactive interpreter 23:09
allison MikeFair: fun to chat ideas with you, it'll be great to see how it grows! 23:14
MikeFair allison: glad you like it, I think you'll also get really interested in the xTalk work as its really a lot more than just a languge 23:15
allison: I heard that the end game for Parrot for you is ultimately a native language interpretter 23:16
allison: Which is what really attracted to me to the project in the first place
:)
dalek rtcl-nqp/nqp2: 17df463 | coke++ | build/Makefile.in:
improve build deps
 23:17
allison MikeFair: I was a big fan of HyperTalk growing up :)
MikeFair: and, yes, Parrot is primarily about tools for implementing languages 23:18
MikeFair: the fact that it happens to be a good place for experimenting with distributed computing is a bonus
MikeFair allison: Excellent!!! Have you experienced 'revolution' yet?
allison: Well what good is a distributed computer if you can't express anything on it!!!?!??!?!? 23:19
:)
allison MikeFair: nope, haven't had a chance to play with Revolution/LiveCode yet 23:20
MikeFair allison: My goal for Safire (or whatever it ends up being called) is that if you can express a formalized english language to make programming commands, then those same abstractions exist in other laguanges
allison: Creating a xTalk byte code would allow a native language code to be translated to/from multiple native languages 23:21
allison: maybe not an actual byte code but some kind of IR/Abstraction Tree 23:22
allison: Then you just have to deal with variable names, which could be done using a dictionary, if the programmers used words in the real dictionary as variable names
allison: Or provided some kind of variable name to dictionary word mapping 23:23
allison: Then that also brings up another reason why I like Parrot for this so much and its because as you introduce new commands to an xTalk, you really, if you're going to do it right, need to make a custom parser just to read your new command. No xTalk interprer I've ever come across has publically considered even attempting this 23:26
allison: So Parrot, by being able to register Grammars at runtime, makes this conceivable 23:27
allison MikeFair: yup, it falls right in Parrot's favorite problem domain 23:28
MikeFair allison: loading a module or external could cause a new command to get registered to parse the new command, or augmentation of an existing command, once you "start using" it 23:29
allison: Then I got a couple other things cooking for making it possible for one person to type USD$100 and having the other person see it as EUR$120 without the programmer really needing to do anything to make that work 23:34
allison: And when you take that all together you have what I'm considering as "the project" I'm working on
:0
:)
allison MikeFair: :)
MikeFair: (I'm fading in and out, prepping for an astrophysics exam today) 23:37
MikeFair allison: That sounds "complicated" :) 23:38
allison MikeFair: nah, it's just math
MikeFair allison: No worries, what I'm mostly excited about is that I think you're the first person I've been able to explain all this to who actually had some semblence of recognition as to what it was I was actually trying to describe
allison MikeFair: yeah, I totally understand that feeling :) 23:39
MikeFair allison: The xTalk folks don't get too technical, the technical folks like crpytic, the single CPU folks have a hard time thinking distributed, the networking folks don't really think 'compilers'
allison MikeFair: hang around this channel, there's lots of "full system" geeks here 23:40
MikeFair allison: The call stack folks have a hard time with messages :)
allison: I kind of got that sense that regardless how difficult it might be for me to get started, i'm in the right place 23:41
allison MikeFair: I've also had that experience trying to explain Parrot
sorear allison: taking or giving?
MikeFair allison: And if I can get as far as a GUI based HyperTalk clone, then I'm clearly winning this game. :)
sorear: I imagine both
allison: I could only imagine 23:42
allison sorear: I'd also say both
sorear allison: I mean the astrophysics exam
allison sorear: oh, taking
sorear: yeah, my background is linguistics and CS, advanced physics is a recent addition 23:43
sorear: fun though :) 23:45
MikeFair allison: I could only imagine the challenges you've experienced explaining parrot to folks 23:47
allison MikeFair: :) 23:48
MikeFair allison: I saw you give a talk on it at SCALE once - and I could tell from the blank expressions on most people's faces they weren't exactly getting everything you were explaining
sorear SCALE? what year? 23:49
MikeFair allison: All I remember thinking was that it was all so cool and it was exactly the kind of thing I needed to make the system multi-lingual xTalk work
sorear: 7x or 8x I believe
I was paying special attention to the context passing paradigm because it was exactly the way "I wished things worked" but I didn't get creative enough to actually think I could use something other than a stack based system 23:52
I just figured it was too hard or something like that and I wasn't about to go invent a whole new computer just to find out people had already proven it couldn't be done 23:53
So I had just accepted the stack based world as my only paradigm but knew/wished for something else, something more fluid 23:54
Suffice it say I think it's really cool 23:55
the whle thing
sorear MikeFair: doesn't the "L" stand for Linux?
so Allison presenting at SCALE in '7x would be a priori impossible, Linux wasn't released until '91 23:56
MikeFair sorear: SCALE 7x
:)
sorear (also I had no idea y'all were that old)
MikeFair sorear: hehe - I'm clearly entering the phase where I can look at the new things being creating and they are begining to come from a different generation of creator 23:58
sorear: It's difficult for me to still consider myself on the 'leading edge'
sorear: Actually, I take that back, it'd be an outright lie
sorear so I guess 'SCALE 7x' does *not* mean "between 1970 and 1979" 23:59
MikeFair sorear: hehe nope- I'm sorry I thought you knew
sorear: It means the 7th SCALE
sorear: This year was 10x

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!