Camelia, the Perl 6 bug

IRC log for #parrot, 2012-09-08

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:12 benabik joined #parrot
00:30 kid51 joined #parrot
01:32 benabik joined #parrot
01:44 MikeFair joined #parrot
02:03 mvorl joined #parrot
02:04 MikeFair Hello there #parrot
02:49 dalek partcl-nqp/nqp2: 868ef43 | coke++ | src/Partcl/commands/time.pm:
02:49 dalek partcl-nqp/nqp2: fixup [time]
02:49 dalek partcl-nqp/nqp2: review: https://github.com/partcl/p​artcl-nqp/commit/868ef430d8
02:49 dalek partcl-nqp/nqp2: 4c10dd8 | coke++ | src/Partcl/commands/info.pm:
02:49 dalek partcl-nqp/nqp2: fixup [info]
02:49 dalek partcl-nqp/nqp2: review: https://github.com/partcl/p​artcl-nqp/commit/4c10dd84ae
02:49 dalek partcl-nqp/nqp2: 488d13d | coke++ | src/Partcl/commands/unset.pm:
02:49 dalek partcl-nqp/nqp2: fixup [unset]
02:49 dalek partcl-nqp/nqp2: review: https://github.com/partcl/p​artcl-nqp/commit/488d13d4b3
02:49 dalek partcl-nqp/nqp2: 0b1e72a | coke++ | src/Partcl/commands/upvar.pm:
02:49 dalek partcl-nqp/nqp2: fixup [upvar]
02:49 dalek partcl-nqp/nqp2: review: https://github.com/partcl/p​artcl-nqp/commit/0b1e72ab56
02:49 dalek partcl-nqp/nqp2: b0ae2f9 | coke++ | src/Partcl/commands/proc.pm:
02:49 dalek partcl-nqp/nqp2: fixup [proc]
02:49 dalek partcl-nqp/nqp2: review: https://github.com/partcl/p​artcl-nqp/commit/b0ae2f9c42
02:49 dalek partcl-nqp/nqp2: f2aa12c | coke++ | src/Partcl/commands/expr.pm:
02:49 dalek partcl-nqp/nqp2: fixup [expr]
02:49 dalek partcl-nqp/nqp2: review: https://github.com/partcl/p​artcl-nqp/commit/f2aa12c3d4
02:49 dalek partcl-nqp/nqp2: b188cf2 | coke++ | src/Partcl/commands/array.pm:
02:49 dalek partcl-nqp/nqp2: fixup [array]
02:49 dalek partcl-nqp/nqp2: review: https://github.com/partcl/p​artcl-nqp/commit/b188cf2d02
05:31 contingencyplan joined #parrot
06:00 mvorl joined #parrot
08:19 Psyche^ joined #parrot
09:52 mvorl joined #parrot
11:37 whiteknight joined #parrot
11:40 JimmyZ joined #parrot
11:54 dalek nqp: b4dec6c | jnthn++ | src/PASTRegex.pir:
11:54 dalek nqp: Stop exporting the dummy PAST package.
11:54 dalek nqp: review: https://github.com/perl6/nqp/commit/b4dec6cdac
11:54 dalek nqp: e19b5fd | jnthn++ | src/stage0/ (9 files):
11:54 dalek nqp: Update stage0 to eliminate PAST package cross-refs.
11:54 dalek nqp: review: https://github.com/perl6/nqp/commit/e19b5fda95
11:54 dalek nqp: 1ff9f02 | jnthn++ | src/PASTRegex.pir:
11:54 dalek nqp: Further gut the PAST inclusion code.
11:54 dalek nqp: review: https://github.com/perl6/nqp/commit/1ff9f02beb
12:00 whiteknight good morning, #parrot
12:08 JimmyZ joined #parrot
12:17 dalek nqp: 718a3fc | jnthn++ | src/ (5 files):
12:17 dalek nqp: Eliminate a bunch more PAST references.
12:17 dalek nqp: review: https://github.com/perl6/nqp/commit/718a3fcba9
12:18 dalek rakudo/nom: 0ead9e4 | jnthn++ | tools/build/NQP_REVISION:
12:18 dalek rakudo/nom: Bump to an NQP that doesn't load/import PAST.
12:18 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/0ead9e4d87
12:56 kid51 joined #parrot
13:38 PacoAir joined #parrot
14:18 Khisanth joined #parrot
14:58 JimmyZ joined #parrot
17:48 MikeFair joined #parrot
17:57 MikeFair Howdy #parrot! :)
18:14 nopaste "Allison" at 202.71.99.222 pasted "I'm from England <a href=" http://purchasekamagra.devhub.com/ ">Purchase Kamagra </a> from a manual claim. <a href=" http://cheapkamagra.devhub.com/ ">Cheap K" (6 lines) at http://nopaste.snit.ch/164365
18:14 allison wow, I wish they'd stop using my name for IRC spam :)
18:16 allison pastebot needs captcha
18:28 whiteknight hello MikeFair
18:28 whiteknight hello allison
18:37 benabik joined #parrot
18:39 MikeFair whiteknight: Hi there
18:41 allison hi whiteknight :)
18:53 MikeFair allison / whiteknight: I had some ideas /questions to run by you guys
18:54 MikeFair 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:55 MikeFair 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 MikeFair Then I was thinking / looking at Namespaces in programming languages, like the one I'm thinking of and parrot
18:56 MikeFair and what struck me was the similarities between namespaces in programming languages and network routing
18:57 MikeFair 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:58 MikeFair I selected 24-bits because that lines up with the register size of the NVidia GPU cards
18:59 MikeFair Coincidentally, putting the two 24-bit identifiers together (Namespace::identifier) == one single 48-bit identifier == the same length as an ethernet MAC address
19:02 MikeFair 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:04 MikeFair 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:05 MikeFair 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 contingencyplan joined #parrot
19:06 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:08 MikeFair 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 MikeFair Instead of the Parrot VM receiving a block of memory to execute, it would receive a queue of instructions
19:10 MikeFair 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:14 MikeFair 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:17 MikeFair Gotta go, family is going out to lunch, bbl, and BTW:
19:17 MikeFair Thanks for parrot!!!  It's inspiring! :)
19:18 mvorl joined #parrot
19:19 tadzik :)
19:23 lucian joined #parrot
19:33 schmooster joined #parrot
20:02 allison MikeFair: It sounds like a very interesting project.
20:03 allison MikeFair: I recently worked with ZeroMQ on a smart home project, where the "brain" consisted of a collection of networked nodes communicating
20:03 allison MikeFair: I was impressed at how lightweight it is, it would work quite well with Parrot
20:04 allison MikeFair: and, it already has C bindings, so would link in easily
20:08 MikeFair allison: great to hear
20:08 MikeFair 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
20:09 MikeFair allison: And the one thing they haven't really worked out is creating their own namespace framework
20:12 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 :)
20:12 allison but nothing structured
20:12 MikeFair allison: Which is really more of a "topic" kind of concept
20:12 MikeFair :)
20:13 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
20:14 MikeFair 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:15 MikeFair allison: At that point you'd likely be talking to parrot and grammars
20:15 MikeFair :)
20:16 MikeFair That's the kind of vision I've got going for it
20:16 MikeFair 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
20:17 MikeFair So the concept of running a Parrot VM on each processor in the GPU seems to work out well, at least in concept
20:18 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:)
20:18 MikeFair allison: That's exactly it
20:19 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
20:19 allison and, machines could have some form of caching, so code isn't resend constantly
20:20 allison or even remote loading, for common libraries
20:20 MikeFair allison: Exactly!  Are you familiar with the nomachine stuff for the X server protocl?
20:20 MikeFair allison: that's more like what I was thinking, actually a distributed version control system for libraries at some point
20:20 allison only the general principles, I haven't gotten into the code
20:21 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 MikeFair allison: That 'instance' gets an ID, the id says 'these variables change each time I call and these values are static'
20:22 MikeFair allison: I think technically they predetermine the registered functions
20:22 MikeFair allison: So its like one step below MMD
20:22 MikeFair allison: In addition to dispatching on types, they can dispatch on 'differing values'
20:23 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'
20:24 MikeFair 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 MikeFair allison: (and the only thing they need to send are the X,Y coordinates to draw it at)
20:25 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
20:25 MikeFair :)
20:26 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 :)
20:26 allison and, only a few variants each time
20:27 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:28 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 allison ?
20:28 allison I've been working a lot lately with JSON RPC-based services
20:28 MikeFair allison: I was thinking the source code would generate an MD5SUM or a SHA1 and that would get registered with the network
20:29 MikeFair 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?
20:29 MikeFair allison: they could, what would happen is the interface (function signature) has one key, and that gets bound to another function key
20:30 MikeFair allison: So the service provider side says "I'm publishing these signatures" and then saying "and they are executed/bound to these functions"
20:31 MikeFair allison: If a node didn't have that function implementation it could ask for it
20:31 MikeFair allison: I'm thinking of multiple implementations for generating a SHA1 key as an example
20:31 MikeFair allison: Let's say one does it wrong
20:31 allison in a distributed fashion, like DNS propagation?
20:31 MikeFair allison: Or just different from the others
20:31 allison (so, it could ask its neighbor, not just a central service?)
20:32 MikeFair allison: Yeah, but its more tightly knit, yes, the central service
20:32 MikeFair allison: "You have a 24-bit address space in which to register your neighbor namespaces"
20:32 MikeFair allison: "they'll tell you their ID and you tell them yours
20:32 MikeFair allison: Within a one hop mesh, all addresses are unique
20:33 MikeFair allison: Each of them, can then announce/publicize their distinct entities within their 24-bit space
20:34 MikeFair allison: The combination of 24-bit namespace and 24-bit id = one 48-bit "pointer" to something in the mesh
20:35 MikeFair 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 MikeFair 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
20:36 MikeFair So namespace packages A::B::C::D would suck 'D' into my local space
20:37 MikeFair but I'd send the request through A when I wanted to atlk to it
20:37 MikeFair I haven't exactly worked that part out yet
20:37 MikeFair 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
20:38 MikeFair I think what happens is I make 'D' one of my 16.7 million nodes that my namespace can connect to
20:39 MikeFair allison: hehe - I actually mispoke earlier about the central service
20:39 MikeFair allison: it's not the central service model, it's the neighbor query model
20:39 allison yes, the neighbor model is more powerful in a mesh
20:40 allison 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
20:40 moritz though easier to guard against races (the central model)
20:41 MikeFair moritz: My plan, I think, is to force agreement between two nodes
20:41 MikeFair moritz: So each "link" can only talk about 16.7 million things
20:41 allison MikeFair: you might look at PXE booting as a model
20:41 MikeFair moritz: Node A and Node B have to agree that X refers to the same thing on both sides
20:42 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
20:43 MikeFair 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 MikeFair and the node keep tracks of the mapping like a big NAT table
20:44 MikeFair allison: I'll look at that, I haven't looked at PXE before (though I've used it occasionally)
20:47 MikeFair 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:48 MikeFair 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 MikeFair Or at least figure out who to talk to about certain pieces of the code :)
20:49 * MikeFair gets called away to take his daughter for soccer pictures. :)
20:49 MikeFair allison / moritz: thanks for the feedback! I'll be back later. :)
20:50 allison MikeFair: enjoy the soccer!
20:51 allison MikeFair: (and you might start with a simple winxed library, as a proof of concept)
21:05 alvis joined #parrot
22:13 * MikeFair is back. :)
22:15 MikeFair allison: We enjoyed ourselves, the girls took a beautiful picture, and it should turn out nice! :)
22:17 MikeFair allison: I was thinking about being brain dead about it initially and adding a ZMQ socket to my base PMC object
22:17 MikeFair allison: I'm assuming everything I'd ever want to talk to will be some derivation of a PMC somehow
22:19 MikeFair 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 MikeFair using PAIR
22:19 MikeFair allison: Then I'd jsut need to get namespaces to PAIR with each other
22:20 MikeFair along the way I'll likely realize how wrong that design is and then see what it really needs to be
22:20 MikeFair I'm expecting some combination of PUB/SUB REQ/REP and REP/REQ
22:20 MikeFair Perhaps certain objects acting a broker devices for other objects
22:22 MikeFair 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:24 MikeFair 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
22:25 allison 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
22:27 MikeFair 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?!
22:27 MikeFair allison: So in my world, Parrot would get 16.7 million registers per PMC
22:27 allison MikeFair: aye, and best to construct your own id scheme, rather than using implementation details inside the VM
22:28 allison 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. :)
22:29 MikeFair 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:30 MikeFair nesting / NATing of addresses I've got planned it should scale really well
22:32 MikeFair 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:33 benabik joined #parrot
22:33 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:34 MikeFair but that's in the "we'll get there" category atm let's make 'as designed ' work first before "cheating" :)
22:35 MikeFair allison: So what winxed library did you see would be good?
22:35 MikeFair allison: I was thinking I'm doing my language 'Safire' which will eventually get classes
22:36 MikeFair 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
22:37 allison MikeFair: faster for experimenting
22:37 MikeFair allison: agreed, but I had a hard time thinking about "but what would it talk about"
22:37 MikeFair allison: So I was thinking if I created a "Root" namespace that two Parrot VMS could share
22:37 allison MikeFair: then move a level  deeper as you're comfortable you're heading in the right direction
22:38 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
22:39 allison MikeFair: as well as the ZMQ interface
22:39 allison (wrapping ZMQ in an object is nicer than working directly with the C bindings)
22:39 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
22:40 MikeFair allison: Well I was thinking a PMC would basically become a ZMQ 'queue' device
22:40 MikeFair allison: and all the magic would 'just happen' inside the PMC implementation
22:41 MikeFair 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 :)
22:41 MikeFair allison: and that's where I'd likely be spending all my time
22:42 MikeFair 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
22:42 MikeFair allison: but perhaps I'm missing something
22:42 MikeFair allison: I was thinking "ZMQ comes for free when you use Parrot"
22:43 MikeFair allison: And automatically builds a peer2peer mesh kind of like erlang does
22:44 allison MikeFair: follow your gut, it can always be refactored later
22:44 MikeFair allison: sounds good.   btw, I like greedy! :)
22:45 MikeFair allison: I plan on using the Microsoft SQL Server Service Broker as something I consider a good mesaging model
22:46 MikeFair 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.
22:46 MikeFair allison: Where the channel/queue represents a link
22:47 MikeFair 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 MikeFair allison:  And make the 'top layer' and make whatever is beneath that do anything required to make my interface 'easy' :)
22:48 MikeFair 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:49 allison MikeFair: it's a good design methodology
22:49 MikeFair And that goes for everyone else too
22:49 MikeFair The key thing is to actually make it useful and transparent
22:49 allison helps avoid the problem of "great idea with an unusable implementation"
22:50 MikeFair (or at least as transparent as is useful to still leave people with the controls need)
22:51 MikeFair 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:52 MikeFair 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 :)
22:53 allison MikeFair: most innovation really is a slight edge forward on what went before
22:53 MikeFair I'm with you there
22:53 sorear don't forget. 'If I have seen further than others it is because I stand on the shoulders of giants.'
22:54 MikeFair exactly!
22:56 MikeFair 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 MikeFair You use Parrot VM and PIR in place of the OpenCL/CUDA code
22:58 MikeFair You let ZeroMQ do its thing as a messaging backbone within and between the packges/namespaces inside the Parrot VM
22:58 MikeFair and let Parrot PMCs take care of the naming/DNS type lookup, resolution, and execution
22:59 MikeFair Lastly, and this is the 'innovative' part, you make it easy to bind the values between PMCs together throughout the distributed system
22:59 MikeFair well actually I just ripped that off from .Net -- well more specifically Micosoft's classes
23:01 MikeFair And their ideas behind a "binding context" and "currency manager"
23:02 MikeFair 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:08 MikeFair 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 MikeFair in concept anyway
23:08 MikeFair :)
23:09 * MikeFair goes back to trying get his "say" statement to work without crashing the interactive interpreter
23:14 allison MikeFair: fun to chat ideas with you, it'll be great to see how it grows!
23:15 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:16 MikeFair allison: I heard that the end game for Parrot for you is ultimately a native language interpretter
23:16 MikeFair allison: Which is what really attracted to me to the project in the first place
23:16 MikeFair :)
23:17 dalek partcl-nqp/nqp2: 17df463 | coke++ | build/Makefile.in:
23:17 dalek partcl-nqp/nqp2: improve build deps
23:17 dalek partcl-nqp/nqp2: review: https://github.com/partcl/p​artcl-nqp/commit/17df46386e
23:17 allison MikeFair: I was a big fan of HyperTalk growing up :)
23:18 allison MikeFair: and, yes, Parrot is primarily about tools for implementing languages
23:18 allison MikeFair: the fact that it happens to be a good place for experimenting with distributed computing is a bonus
23:18 MikeFair allison: Excellent!!! Have you experienced 'revolution' yet?
23:19 MikeFair allison: Well what good is a distributed computer if you can't express anything on it!!!?!??!?!?
23:19 MikeFair :)
23:20 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
23:21 MikeFair allison: Creating a xTalk byte code would allow a native language code to be translated to/from multiple native languages
23:22 MikeFair allison: maybe not an actual byte code but some kind of IR/Abstraction Tree
23:22 MikeFair 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
23:23 MikeFair allison: Or provided some kind of variable name to dictionary word mapping
23:26 MikeFair 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:27 MikeFair allison: So Parrot, by being able to register Grammars at runtime, makes this conceivable
23:28 allison MikeFair: yup, it falls right in Parrot's favorite problem domain
23:29 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:34 MikeFair 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 MikeFair allison: And when you take that all together you have what I'm considering as "the project" I'm working on
23:34 MikeFair :0
23:34 MikeFair :)
23:34 allison MikeFair: :)
23:37 allison MikeFair: (I'm fading in and out, prepping for an astrophysics exam today)
23:38 MikeFair allison: That sounds "complicated" :)
23:38 allison MikeFair: nah, it's just math
23:38 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
23:39 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'
23:40 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 :)
23:41 MikeFair 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
23:41 sorear allison: taking or giving?
23:41 MikeFair allison: And if I can get as far as a GUI based HyperTalk clone, then I'm clearly winning this game. :)
23:41 MikeFair sorear: I imagine both
23:42 MikeFair allison: I could only imagine
23:42 allison sorear: I'd also say both
23:42 sorear allison: I mean the astrophysics exam
23:42 allison sorear: oh, taking
23:43 allison sorear: yeah, my background is linguistics and CS, advanced physics is a recent addition
23:45 allison sorear: fun though :)
23:47 MikeFair allison: I could only imagine the challenges you've experienced explaining parrot to folks
23:48 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
23:49 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
23:49 MikeFair sorear: 7x or 8x I believe
23:52 MikeFair 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:53 MikeFair 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:54 MikeFair So I had just accepted the stack based world as my only paradigm but knew/wished for something else, something more fluid
23:55 MikeFair Suffice it say I think it's really cool
23:55 MikeFair the whle thing
23:55 sorear MikeFair: doesn't the "L" stand for Linux?
23:56 sorear so Allison presenting at SCALE in '7x would be a priori impossible, Linux wasn't released until '91
23:56 MikeFair sorear: SCALE 7x
23:56 MikeFair :)
23:56 sorear (also I had no idea y'all were that old)
23:58 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 MikeFair sorear: It's difficult for me to still consider myself on the 'leading edge'
23:58 MikeFair sorear: Actually, I take that back, it'd be an outright lie
23:59 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
23:59 MikeFair sorear: It means the 7th SCALE
23:59 MikeFair sorear: This year was 10x

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced