Re: [fonc] Error trying to compile COLA
On 2/25/2012 7:48 PM, Julian Leviston wrote: As I understand it, Frank is an experiment that is an extended version of DBJr that sits atop lesserphic, which sits atop gezira which sits atop nile, which sits atop maru all of which which utilise ometa and the worlds idea. If you look at the http://vpri.org/html/writings.php page you can see a pattern of progression that has emerged to the point where Frank exists. From what I understand, maru is the finalisation of what began as pepsi and coke. Maru is a simple s-expression language, in the same way that pepsi and coke were. In fact, it looks to have the same syntax. Nothing is the layer underneath that is essentially a symbolic computer - sitting between maru and the actual machine code (sort of like an LLVM assembler if I've understood it correctly). yes, S-Expressions can be nifty. often, they aren't really something one advertises, or uses as a front-end syntax (much like Prototype-OO and delegation: it is a powerful model, but people also like their classes). so, one ends up building something with a C-like syntax and Class/Instance OO, even if much of the structure internally is built using lists and Prototype-OO. if something is too strange, it may not be received well though (like people may see it and be like just what the hell is this?). better then if everything is just as could be expected. in my case, they are often printed out in debugging messages though, as a lot of my stuff internally is built using lists (I ended up recently devising a specialized network protocol for, among other things, sending compressed list-based messages over a TCP socket). probably not wanting to go too deeply into it, but: it directly serializes/parses the lists from a bitstream; a vaguely JPEG-like escape-tag system is used; messages are Huffman-coded, and make use of both a value MRU/MTF and LZ77 compression (many parts of the coding also borrow from Deflate); currently, I am (in my uses) getting ~60% additional compression vs S-Expressions+Deflate, and approximately 97% compression vs plaintext (plain Deflate got around 90% for this data). the above was mostly used for sending scene-graph updates and similar in my 3D engine, and is maybe overkill, but whatever (although, luckily, it means I can send a lot more data while staying within a reasonable bandwidth budget, as my target was 96-128 kbps, and I am currently using around 8 kbps, vs closer to the 300-400 kbps needed for plaintext). They've hidden Frank in plain sight. He's a patch-together of all their experiments so far... which I'm sure you could do if you took the time to understand each of them and had the inclination. They've been publishing as much as they could all along. The point, though, is you have to understand each part. It's no good if you don't understand it. possibly, I don't understand a lot of it, but I guess part of it may be knowing what to read. there were a few nifty things to read here and there, but I wasn't really seeing the larger whole I guess. If you know anything about Alan VPRI's work, you'd know that their focus is on getting children this stuff in front as many children as possible, because they have so much more ability to connect to the heart of a problem than adults. (Nothing to do with age - talking about minds, not bodies here). Adults usually get in the way with their stuff - their knowledge sits like a kind of a filter, denying them the ability to see things clearly and directly connect to them unless they've had special training in relaxing that filter. We don't know how to be simple and direct any more - not to say that it's impossible. We need children to teach us meta-stuff, mostly this direct way of experiencing and looking, and this project's main aim appears to be to provide them (and us, of course, but not as importantly) with the tools to do that. Adults will come secondarily - to the degree they can't embrace new stuff ;-). This is what we need as an entire populace - to increase our general understanding - to reach breakthroughs previously not thought possible, and fast. Rather than changing the world, they're providing the seed for children to change the world themselves. there are merits and drawbacks here. (what follows here is merely my opinion at the moment, as stated at a time when I am somewhat in need of going to sleep... ). granted, yes, children learning stuff is probably good, but the risk is also that children (unlike adults) are much more likely to play things much more fast and loose regarding the law, and might show little respect for existing copyrights and patents, and may risk creating liability issues, and maybe bringing lawsuits to their parents (like, some company decides to sue the parents because little Johnny just went and infringed on several of their patents, or used some of their IP in a personal project, ...). ( and, in my case, I learned
Re: [fonc] Error trying to compile COLA
What does any of what you just said have to do with the original question about COLA? Julian On 26/02/2012, at 9:25 PM, BGB wrote: On 2/25/2012 7:48 PM, Julian Leviston wrote: As I understand it, Frank is an experiment that is an extended version of DBJr that sits atop lesserphic, which sits atop gezira which sits atop nile, which sits atop maru all of which which utilise ometa and the worlds idea. If you look at the http://vpri.org/html/writings.php page you can see a pattern of progression that has emerged to the point where Frank exists. From what I understand, maru is the finalisation of what began as pepsi and coke. Maru is a simple s-expression language, in the same way that pepsi and coke were. In fact, it looks to have the same syntax. Nothing is the layer underneath that is essentially a symbolic computer - sitting between maru and the actual machine code (sort of like an LLVM assembler if I've understood it correctly). yes, S-Expressions can be nifty. often, they aren't really something one advertises, or uses as a front-end syntax (much like Prototype-OO and delegation: it is a powerful model, but people also like their classes). so, one ends up building something with a C-like syntax and Class/Instance OO, even if much of the structure internally is built using lists and Prototype-OO. if something is too strange, it may not be received well though (like people may see it and be like just what the hell is this?). better then if everything is just as could be expected. in my case, they are often printed out in debugging messages though, as a lot of my stuff internally is built using lists (I ended up recently devising a specialized network protocol for, among other things, sending compressed list-based messages over a TCP socket). probably not wanting to go too deeply into it, but: it directly serializes/parses the lists from a bitstream; a vaguely JPEG-like escape-tag system is used; messages are Huffman-coded, and make use of both a value MRU/MTF and LZ77 compression (many parts of the coding also borrow from Deflate); currently, I am (in my uses) getting ~60% additional compression vs S-Expressions+Deflate, and approximately 97% compression vs plaintext (plain Deflate got around 90% for this data). the above was mostly used for sending scene-graph updates and similar in my 3D engine, and is maybe overkill, but whatever (although, luckily, it means I can send a lot more data while staying within a reasonable bandwidth budget, as my target was 96-128 kbps, and I am currently using around 8 kbps, vs closer to the 300-400 kbps needed for plaintext). They've hidden Frank in plain sight. He's a patch-together of all their experiments so far... which I'm sure you could do if you took the time to understand each of them and had the inclination. They've been publishing as much as they could all along. The point, though, is you have to understand each part. It's no good if you don't understand it. possibly, I don't understand a lot of it, but I guess part of it may be knowing what to read. there were a few nifty things to read here and there, but I wasn't really seeing the larger whole I guess. If you know anything about Alan VPRI's work, you'd know that their focus is on getting children this stuff in front as many children as possible, because they have so much more ability to connect to the heart of a problem than adults. (Nothing to do with age - talking about minds, not bodies here). Adults usually get in the way with their stuff - their knowledge sits like a kind of a filter, denying them the ability to see things clearly and directly connect to them unless they've had special training in relaxing that filter. We don't know how to be simple and direct any more - not to say that it's impossible. We need children to teach us meta-stuff, mostly this direct way of experiencing and looking, and this project's main aim appears to be to provide them (and us, of course, but not as importantly) with the tools to do that. Adults will come secondarily - to the degree they can't embrace new stuff ;-). This is what we need as an entire populace - to increase our general understanding - to reach breakthroughs previously not thought possible, and fast. Rather than changing the world, they're providing the seed for children to change the world themselves. there are merits and drawbacks here. (what follows here is merely my opinion at the moment, as stated at a time when I am somewhat in need of going to sleep... ). granted, yes, children learning stuff is probably good, but the risk is also that children (unlike adults) are much more likely to play things much more fast and loose regarding the law, and might show little respect for existing copyrights and patents, and may risk creating liability issues, and maybe bringing lawsuits to their parents
Re: [fonc] Error trying to compile COLA
On 2/26/2012 3:53 AM, Julian Leviston wrote: What does any of what you just said have to do with the original question about COLA? sorry, I am really not good with topic, was just trying to respond to what was there, but it was 2AM... (hmm, maybe I should have waited until morning? oh well...). as for getting COLA to compile, I have little idea, hence why I did not comment on this. it seemed to be going off in the direction of motivations, ... which I can comment on. likewise, I can comment on Prototype OO and S-Expressions, since I have a lot more experience using these, ... (both, just so happen, are things that seem to be seen very negatively by average programmers, vs say Class/Instance and XML, ...). however, both continue to be useful, so they don't just go away (like, Lists/S-Exps are easier to work with than XML via DOM or similar, ...). but, yes, maybe I will go back into lurk mode now... Julian On 26/02/2012, at 9:25 PM, BGB wrote: On 2/25/2012 7:48 PM, Julian Leviston wrote: As I understand it, Frank is an experiment that is an extended version of DBJr that sits atop lesserphic, which sits atop gezira which sits atop nile, which sits atop maru all of which which utilise ometa and the worlds idea. If you look at the http://vpri.org/html/writings.php page you can see a pattern of progression that has emerged to the point where Frank exists. From what I understand, maru is the finalisation of what began as pepsi and coke. Maru is a simple s-expression language, in the same way that pepsi and coke were. In fact, it looks to have the same syntax. Nothing is the layer underneath that is essentially a symbolic computer - sitting between maru and the actual machine code (sort of like an LLVM assembler if I've understood it correctly). yes, S-Expressions can be nifty. often, they aren't really something one advertises, or uses as a front-end syntax (much like Prototype-OO and delegation: it is a powerful model, but people also like their classes). so, one ends up building something with a C-like syntax and Class/Instance OO, even if much of the structure internally is built using lists and Prototype-OO. if something is too strange, it may not be received well though (like people may see it and be like just what the hell is this?). better then if everything is just as could be expected. in my case, they are often printed out in debugging messages though, as a lot of my stuff internally is built using lists (I ended up recently devising a specialized network protocol for, among other things, sending compressed list-based messages over a TCP socket). probably not wanting to go too deeply into it, but: it directly serializes/parses the lists from a bitstream; a vaguely JPEG-like escape-tag system is used; messages are Huffman-coded, and make use of both a value MRU/MTF and LZ77 compression (many parts of the coding also borrow from Deflate); currently, I am (in my uses) getting ~60% additional compression vs S-Expressions+Deflate, and approximately 97% compression vs plaintext (plain Deflate got around 90% for this data). the above was mostly used for sending scene-graph updates and similar in my 3D engine, and is maybe overkill, but whatever (although, luckily, it means I can send a lot more data while staying within a reasonable bandwidth budget, as my target was 96-128 kbps, and I am currently using around 8 kbps, vs closer to the 300-400 kbps needed for plaintext). They've hidden Frank in plain sight. He's a patch-together of all their experiments so far... which I'm sure you could do if you took the time to understand each of them and had the inclination. They've been publishing as much as they could all along. The point, though, is you have to understand each part. It's no good if you don't understand it. possibly, I don't understand a lot of it, but I guess part of it may be knowing what to read. there were a few nifty things to read here and there, but I wasn't really seeing the larger whole I guess. If you know anything about Alan VPRI's work, you'd know that their focus is on getting children this stuff in front as many children as possible, because they have so much more ability to connect to the heart of a problem than adults. (Nothing to do with age - talking about minds, not bodies here). Adults usually get in the way with their stuff - their knowledge sits like a kind of a filter, denying them the ability to see things clearly and directly connect to them unless they've had special training in relaxing that filter. We don't know how to be simple and direct any more - not to say that it's impossible. We need children to teach us meta-stuff, mostly this direct way of experiencing and looking, and this project's main aim appears to be to provide them (and us, of course, but not as importantly) with the tools to do that. Adults will come secondarily - to the degree they can't embrace new stuff
Re: [fonc] Error trying to compile COLA
Guys, I find these off_topic comments (as in not strictly about my idst compilation problem) really interesting. Maybe I should start a new thread? Something like «how can a newbie start playing with this technology?». Thanks! ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] OT? S-Exps and network (Re: Error trying to compile COLA)
On 2/26/2012 11:33 AM, Martin Baldan wrote: Guys, I find these off_topic comments (as in not strictly about my idst compilation problem) really interesting. Maybe I should start a new thread? Something like «how can a newbie start playing with this technology?». Thanks! well, ok, hopefully everyone can tolerate my OT-ness here... (and hopefully, my forays deep into the land of trivia...). well, ok, I am not personally associated with VPRI though, mostly just lurking and seeing if any interesting topics come up (but, otherwise, am working independently on my own technology, which includes some VM stuff and a 3D engine). ( currently, no code is available online, but parts can be given on request via email or similar if anyone is interested, likewise goes for specs, ... ) recently, I had worked some on adding networking support for my 3D engine, but the protocol is more generic (little about it is particularly specific to 3D gaming, and so could probably have other uses). internally, the messaging is based on lists / S-Expressions (it isn't really clear which term is better, as lists is too generic, and S-Expressions more refers to the syntax, rather than their in-program representation... actually it is a similar terminology problem with XML, where the term may ambiguously either be used for the textual representation, or for alternative non-text representations of the payload, IOW: Binary XML, and similar). but, either way, messages are passed point-to-point as lists, typically using a structure sort of like: (wdelta ... (delta 315 (org 140 63 400) (ang 0 0 120) ...) ...) the messages are free-form (there is no schema, as the system will try to handle whatever messages are thrown at it, but with the typical default behavior for handlers of ignoring anything which isn't recognized, and the protocol/codec is agnostic to the types or format of the messages it is passing along, provided as long as they are built from lists or similar...). as-is, these expressions are not eval'ed per-se, although the typical message handling could be itself regarded as a crude evaluator (early versions of my original Scheme interpreter were not actually all that much different). theoretically, things like ASTs or Scheme code or whatever could be easily passed over the connection as well. in-program, the lists are dynamically typed, and composed primarily of chains of cons cells, with symbols, fixnums, flonums, strings, ... comprising most of the structure (these are widely used in my projects, but aren't particularly unique to my project, though seemingly less well-known to most more mainstream programmers). as-is, currently a small subset of the larger typesystem is handled, and I am currently ignoring the matter of list cycles or object-identity (data is assumed acyclic, and currently everything is passed as a copy). at the high-level, the process currently mostly looks like: process A listens on a port, and accepts connections, and then handles any messages which arrive over these connections, and may transmit messages in response. process B connects to A, and may likewise send and receive messages. currently, each end basically takes whatever messages are received, and passes them off to message-processing code (walks the message expressions and does whatever). currently, queues are commonly used for both incoming and outgoing messages, and most messages are asynchronous. neither end currently needs to worry about the over-the-wire format of these lists. a system resembling XMPP could probably also be built easily enough (and may end up being done anyways). lists were chosen over XML mostly for sake of them being more convenient to work with. actually, I did something similar to all this long ago, but this effort fell into oblivion and similar had not been done again until fairly recently (partly involving me reviving some old forgotten code of mine...). now, on to the protocol itself: it is currently built over raw TCP sockets (currently with nodelay set); messages are encoded into lumps, which are basically tags followed by message data (lumps are also used for stream-control purposes, and may relay other types of messages as well). currently, a system of tags resembling the one in JPEG is used, except that the tags are 4 bytes (with 3 bytes of magic and 1 byte to indicate the tag type, a longer magic was used to reduce the number of times it would need to be escaped in a bitstream). currently, no length is used (instead, one knows a complete message lump has been received because the end-tag is visible). this currently means an 8 byte overhead per-message lump due to tags (there are also Deflate lumps, but these have the added overhead of a decoded-length and a checksum, needed for technical reasons, leading to 16 bytes of overhead). message lumps are themselves a bitstream, and are currently built out of a collection of
Re: [fonc] Error trying to compile COLA
Julian, Thanks, now I have a much better picture of the overall situation, although I still have a lot of reading to do. I already had read a couple of Frank progress reports, and some stuff about worlds, in the publications link you mention. So I thought, this sounds great, how can I try this? Then I went to the wiki, and there was a section called Fundamental new computing technologies, so I said this is the thing!. But no, the real thing was, as you said, hidden in plain sight, under the unconspicuous titles such as Other prototypes and projects related to our work and experiment. I wonder, is that some kind of prank for the uninitiated? hehe. By the way, I've played a little with Squeak, Croquet and other great projects by Alan and the other wonderful Smalltalk people, so I did have a sense of their focus on children. I must confess I was a bit annoyed with what seemed to me like Jedi elitism (as in He is too old. Yes, too old to begin the training. ) but hey, their project, their code, their rules. So, to get back on topic, I've downloaded Maru, The contents are: boot-eval.c boot.l emit.l eval.l Makefile So, the .l files are So this is the file extension for Maru's implementation language (does it have a name?). Sure enough, the very first line of eval.l reads: ;;; -*- coke -*- This made me smile. Well, actually it was a mad laughter. It compiles beautifully. Yay! Now there are some .s files. They look like assembler code. I thought it was Nothing code, but the Maru webpage explains it's just ia-32. Oh, well. I don't know yet where Nothing enters the picture. So, this is compiled to .o files and linked to build the eval executable, which can take .l files and make a new eval executable, and so on. So far so good. But what else can I do with it? Should I use it to run the examples at http://tinlizzie.org/dbjr/; ? All I see is files with a .lbox file extension. What are those? Apparently, there are no READMEs. Could you please give me an example of how to try one of those experiments? Thanks for your tips and patience ;) On Sun, Feb 26, 2012 at 3:48 AM, Julian Leviston jul...@leviston.netwrote: As I understand it, Frank is an experiment that is an extended version of DBJr that sits atop lesserphic, which sits atop gezira which sits atop nile, which sits atop maru all of which which utilise ometa and the worlds idea. If you look at the http://vpri.org/html/writings.php page you can see a pattern of progression that has emerged to the point where Frank exists. From what I understand, maru is the finalisation of what began as pepsi and coke. Maru is a simple s-expression language, in the same way that pepsi and coke were. In fact, it looks to have the same syntax. Nothing is the layer underneath that is essentially a symbolic computer - sitting between maru and the actual machine code (sort of like an LLVM assembler if I've understood it correctly). They've hidden Frank in plain sight. He's a patch-together of all their experiments so far... which I'm sure you could do if you took the time to understand each of them and had the inclination. They've been publishing as much as they could all along. The point, though, is you have to understand each part. It's no good if you don't understand it. If you know anything about Alan VPRI's work, you'd know that their focus is on getting children this stuff in front as many children as possible, because they have so much more ability to connect to the heart of a problem than adults. (Nothing to do with age - talking about minds, not bodies here). Adults usually get in the way with their stuff - their knowledge sits like a kind of a filter, denying them the ability to see things clearly and directly connect to them unless they've had special training in relaxing that filter. We don't know how to be simple and direct any more - not to say that it's impossible. We need children to teach us meta-stuff, mostly this direct way of experiencing and looking, and this project's main aim appears to be to provide them (and us, of course, but not as importantly) with the tools to do that. Adults will come secondarily - to the degree they can't embrace new stuff ;-). This is what we need as an entire populace - to increase our general understanding - to reach breakthroughs previously not thought possible, and fast. Rather than changing the world, they're providing the seed for children to change the world themselves. This is only as I understand it from my observation. Don't take it as gospel or even correct, but maybe you could use it to investigate the parts of frank a little more and with in-depth openness :) The entire project is an experiment... and that's why they're not coming out and saying hey guys this is the product of our work - it's not a linear building process, but an intensively creative process, and most of that happens within oneself before any results are seen (rather like boiling a
Re: [fonc] Error trying to compile COLA
Take a look at the page: http://piumarta.com/software/maru/ it has the original version you have + current. There is a short readme in the current version with some examples that will get you going. David On Sun, Feb 26, 2012 at 6:14 PM, Martin Baldan martino...@gmail.com wrote: Julian, Thanks, now I have a much better picture of the overall situation, although I still have a lot of reading to do. I already had read a couple of Frank progress reports, and some stuff about worlds, in the publications link you mention. So I thought, this sounds great, how can I try this? Then I went to the wiki, and there was a section called Fundamental new computing technologies, so I said this is the thing!. But no, the real thing was, as you said, hidden in plain sight, under the unconspicuous titles such as Other prototypes and projects related to our work and experiment. I wonder, is that some kind of prank for the uninitiated? hehe. By the way, I've played a little with Squeak, Croquet and other great projects by Alan and the other wonderful Smalltalk people, so I did have a sense of their focus on children. I must confess I was a bit annoyed with what seemed to me like Jedi elitism (as in He is too old. Yes, too old to begin the training. ) but hey, their project, their code, their rules. So, to get back on topic, I've downloaded Maru, The contents are: boot-eval.c boot.l emit.l eval.l Makefile So, the .l files are So this is the file extension for Maru's implementation language (does it have a name?). Sure enough, the very first line of eval.l reads: ;;; -*- coke -*- This made me smile. Well, actually it was a mad laughter. It compiles beautifully. Yay! Now there are some .s files. They look like assembler code. I thought it was Nothing code, but the Maru webpage explains it's just ia-32. Oh, well. I don't know yet where Nothing enters the picture. So, this is compiled to .o files and linked to build the eval executable, which can take .l files and make a new eval executable, and so on. So far so good. But what else can I do with it? Should I use it to run the examples at http://tinlizzie.org/dbjr/; ? All I see is files with a .lbox file extension. What are those? Apparently, there are no READMEs. Could you please give me an example of how to try one of those experiments? Thanks for your tips and patience ;) On Sun, Feb 26, 2012 at 3:48 AM, Julian Leviston jul...@leviston.net wrote: As I understand it, Frank is an experiment that is an extended version of DBJr that sits atop lesserphic, which sits atop gezira which sits atop nile, which sits atop maru all of which which utilise ometa and the worlds idea. If you look at the http://vpri.org/html/writings.php page you can see a pattern of progression that has emerged to the point where Frank exists. From what I understand, maru is the finalisation of what began as pepsi and coke. Maru is a simple s-expression language, in the same way that pepsi and coke were. In fact, it looks to have the same syntax. Nothing is the layer underneath that is essentially a symbolic computer - sitting between maru and the actual machine code (sort of like an LLVM assembler if I've understood it correctly). They've hidden Frank in plain sight. He's a patch-together of all their experiments so far... which I'm sure you could do if you took the time to understand each of them and had the inclination. They've been publishing as much as they could all along. The point, though, is you have to understand each part. It's no good if you don't understand it. If you know anything about Alan VPRI's work, you'd know that their focus is on getting children this stuff in front as many children as possible, because they have so much more ability to connect to the heart of a problem than adults. (Nothing to do with age - talking about minds, not bodies here). Adults usually get in the way with their stuff - their knowledge sits like a kind of a filter, denying them the ability to see things clearly and directly connect to them unless they've had special training in relaxing that filter. We don't know how to be simple and direct any more - not to say that it's impossible. We need children to teach us meta-stuff, mostly this direct way of experiencing and looking, and this project's main aim appears to be to provide them (and us, of course, but not as importantly) with the tools to do that. Adults will come secondarily - to the degree they can't embrace new stuff ;-). This is what we need as an entire populace - to increase our general understanding - to reach breakthroughs previously not thought possible, and fast. Rather than changing the world, they're providing the seed for children to change the world themselves. This is only as I understand it from my observation. Don't take it as gospel or even correct, but maybe you could use it to investigate the parts of frank a little more and with
Re: [fonc] Error trying to compile COLA
On 2012-02-27 02:14AM, Martin Baldan wrote: But what else can I do with it? Should I use it to run the examples at http://tinlizzie.org/dbjr/;? All I see is files with a .lbox file extension. What are those? Apparently, there are no READMEs. Could you please give me an example of how to try one of those experiments? DBJr seems to be a Squeak thing. Each of those .lbox directories has a SISS file which seems to be an S-expression serialization of Smalltalk objects. Sounds like probably what you need is the stuff under Text Field Spec for LObjects on the VPRI wiki page. Not that I know *anything* about this whatsoever... --Josh ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
I'm afraid that I am in no way a teacher of this. I'm in no way professing to know what I'm talking about - I've simply given you my observations. Perhaps we can help each other, because I'm intensely interested, too... I want to understand this stuff because it is chock full of intensely powerful ideas. The elitism isn't true... I've misrepresented what I was meaning to say - I simply meant that people who aren't fascinated enough to understand won't have the drive to understand it... until it gets to a kind of point where enough people care to explain it to the people who take longer to understand... This makes sense. It's how it has always been. Sorry for making it sound elitist. It's not, I promise you. When your time is limited, though (as the VPRI guys' time is), one needs to focus on truly expounding it to as many people as you can, so one can teach more teachers first... one teaches the people who can understand the quickest first, and then they can propagate and so on... I hope this is clear. I don't think it was a prank. It's not really hidden at all. If you pay attention, all the components of Frank are there... like I said. It's obviously missing certain things like Nothing, and other optimisations, but for the most part, all the tech is present. My major stumbling block at the moment is understanding OMeta fully. This is possibly the most amazing piece of work I've seen in a long, long time, and there's no easy explanation of it, and no really simple explanation of the syntax, either. There are the papers, and source code and the sandboxes, but I'm still trying to understand how to use it. It's kind of huge. I think perhaps I need to get a grounding in PEGs before I start on OMeta because there seems to be a lot of assumed knowledge there. Mostly I'm having trouble with the absolute, complete basics. Anyway I digress... have you had a look at this file?: http://piumarta.com/software/maru/maru-2.1/test-pepsi.l Just read the whole thing - I found it fairly interesting :) He's build pepsi on maru there... that's pretty fascinating, right? Built a micro smalltalk on top of the S-expression language... and then does a Fast Fourier Transform test using it... I'm not really sure how it relates to this, tho: I actually have no idea about how to run one of the experiments you're talking about - the mbox files... from what I've read about STEPS, though, I think the mbox files are Frank documents... and I think Frank is kinda DBJr... at least, if you go to this page and look at the bottom, pay some careful attention to the video that appears there demonstrating some of the patchwork doll that is frank (if you haven't seen it already)... http://www.vpri.org/vp_wiki/index.php/Gezira http://tinlizzie.org/~bert/Gezira.mp4 In the tinlizzie.org/updates/exploratory/packages you'll find montecello packages that contains some of experiments, I'm fairly sure, one of which is: (yep, you guessed it) FrankVersion-yo.16.mcz However, having not tried this, I'm not sure of what it may be ;-) (if I were you, I'd take a squizz around those packages) You probably what the Lobjects stuff and the doc editor, I'm guessing... :-S Fairly patchy at the best, but that's the point - it's called Frank, as in frankenstein's monster - as in... it's a patchy mess, but it's alive... this stuff is a fair way off having a full stack that operates beautifully... but it's a start... (it seems). Julian On 27/02/2012, at 12:14 PM, Martin Baldan wrote: Julian, Thanks, now I have a much better picture of the overall situation, although I still have a lot of reading to do. I already had read a couple of Frank progress reports, and some stuff about worlds, in the publications link you mention. So I thought, this sounds great, how can I try this? Then I went to the wiki, and there was a section called Fundamental new computing technologies, so I said this is the thing!. But no, the real thing was, as you said, hidden in plain sight, under the unconspicuous titles such as Other prototypes and projects related to our work and experiment. I wonder, is that some kind of prank for the uninitiated? hehe. By the way, I've played a little with Squeak, Croquet and other great projects by Alan and the other wonderful Smalltalk people, so I did have a sense of their focus on children. I must confess I was a bit annoyed with what seemed to me like Jedi elitism (as in He is too old. Yes, too old to begin the training. ) but hey, their project, their code, their rules. So, to get back on topic, I've downloaded Maru, The contents are: boot-eval.c boot.l emit.l eval.l Makefile So, the .l files are So this is the file extension for Maru's implementation language (does it have a name?). Sure enough, the very first line of eval.l reads: ;;; -*- coke -*- This made me smile. Well, actually it was a mad laughter. It compiles beautifully. Yay!
Re: [fonc] Error trying to compile COLA
On 2/26/2012 8:23 PM, Julian Leviston wrote: I'm afraid that I am in no way a teacher of this. I'm in no way professing to know what I'm talking about - I've simply given you my observations. Perhaps we can help each other, because I'm intensely interested, too... I want to understand this stuff because it is chock full of intensely powerful ideas. yep, generally agreed. I generally look for interesting or useful ideas, but admittedly have a harder time understanding a lot of what is going on or being talked about here (despite being, I think, generally being fairly knowledgeable about most things programming-related). there may be a domain mismatch or something though. admittedly, I have not generally gotten as far as being really able to understand Smalltalk code either, nor for that matter languages too much different from vaguely C-like Procedural/OO languages, except maybe ASM, which I personally found not particularly difficult to learn/understand or read/write, but the main drawbacks of ASM being its verbosity and portability issues. granted, this may be partly a matter of familiarity or similar, since I encountered both C and ASM (along with BASIC) at fairly young age (and actually partly came to understand C originally to some degree by looking at the compiler's ASM output, getting a feel for how the constructs mapped to ASM operations, ...). The elitism isn't true... I've misrepresented what I was meaning to say - I simply meant that people who aren't fascinated enough to understand won't have the drive to understand it... until it gets to a kind of point where enough people care to explain it to the people who take longer to understand... This makes sense. It's how it has always been. Sorry for making it sound elitist. It's not, I promise you. When your time is limited, though (as the VPRI guys' time is), one needs to focus on truly expounding it to as many people as you can, so one can teach more teachers first... one teaches the people who can understand the quickest first, and then they can propagate and so on... I hope this is clear. similarly, I was not meaning to apply that children having knowledge is a bad thing, but sadly, it seems to run contrary to common cultural expectations. granted, it is possibly the case that some aspects of culture are broken in some ways, namely, that children are kept in the dark, and there is this notion that everyone should be some sort of unthinking and passive consumer. except, of course, for the content producers, which would generally include both the media industry (TV, movies, music, ...) as a whole and to a lesser extent the software industry, with a sometimes questionable set of Intellectual Property laws in an attempt to uphold the status quo (not that IP is necessarily bad, but it could be better). I guess this is partly why things like FOSS exist. but, FOSS isn't necessarily entirely perfect either. but, yes, both giving knowledge and creating a kind of safe haven seem like reasonable goals, where one can be free to tinker around with things with less risk from some overzealous legal department somewhere. also nice would be if people were less likely to accuse all of ones' efforts of being useless, but sadly, this probably isn't going to happen either. this is not to imply that I personally necessarily have much to offer, as beating against a wall may make one fairly well aware of just how far there is left to go, as relevance is at times a rather difficult goal to reach. admittedly, I am maybe a bit dense as well. I have never really been very good with abstract concepts (nor am I particularly intelligent in the strict sense). but, I am no one besides myself (and have no one besides myself to fall back on), so I have to make due (and hopefully try to avoid annoying people too much, and causing them to despise me, ...). like, the only way out is through and similar. I don't think it was a prank. It's not really hidden at all. If you pay attention, all the components of Frank are there... like I said. It's obviously missing certain things like Nothing, and other optimisations, but for the most part, all the tech is present. sorry for asking, but is their any sort of dense people friendly version, like maybe a description on the Wiki or something?... like, so people can get a better idea of what things are about and how they all work and fit together?... (like, in the top-down description kind of way?). My major stumbling block at the moment is understanding OMeta fully. This is possibly the most amazing piece of work I've seen in a long, long time, and there's no easy explanation of it, and no really simple explanation of the syntax, either. There are the papers, and source code and the sandboxes, but I'm still trying to understand how to use it. It's kind of huge. I think perhaps I need to get a grounding in PEGs before I start on OMeta because
Re: [fonc] Error trying to compile COLA
Hi, Comments line... On 27/02/2012, at 5:33 PM, BGB wrote: I don't think it was a prank. It's not really hidden at all. If you pay attention, all the components of Frank are there... like I said. It's obviously missing certain things like Nothing, and other optimisations, but for the most part, all the tech is present. sorry for asking, but is their any sort of dense people friendly version, like maybe a description on the Wiki or something?... like, so people can get a better idea of what things are about and how they all work and fit together?... (like, in the top-down description kind of way?). I don't think this is for people who aren't prepared to roll up their sleeves and try things out. For a start, learn SmallTalk. It's not hard. Go check out squeak. There are lots of resources to learn SmallTalk. My major stumbling block at the moment is understanding OMeta fully. This is possibly the most amazing piece of work I've seen in a long, long time, and there's no easy explanation of it, and no really simple explanation of the syntax, either. There are the papers, and source code and the sandboxes, but I'm still trying to understand how to use it. It's kind of huge. I think perhaps I need to get a grounding in PEGs before I start on OMeta because there seems to be a lot of assumed knowledge there. Mostly I'm having trouble with the absolute, complete basics. Anyway I digress... have you had a look at this file?: http://piumarta.com/software/maru/maru-2.1/test-pepsi.l Just read the whole thing - I found it fairly interesting :) He's build pepsi on maru there... that's pretty fascinating, right? Built a micro smalltalk on top of the S-expression language... and then does a Fast Fourier Transform test using it... my case: looked some, but not entirely sure how it works though. You could do what I've done, and read the papers and then re-read them and re-read them and re-read them... and research all references you find (the whole site is totally full of references to the entire of programming history). I personally think knowing LISP and SmallTalk, some assembler, C, Self, Javascript and other things is going to be incredibly helpful. Also, math is the most helpful! :) Julian ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Error trying to compile COLA
On 2/26/2012 11:43 PM, Julian Leviston wrote: Hi, Comments line... On 27/02/2012, at 5:33 PM, BGB wrote: I don't think it was a prank. It's not really hidden at all. If you pay attention, all the components of Frank are there... like I said. It's obviously missing certain things like Nothing, and other optimisations, but for the most part, all the tech is present. sorry for asking, but is their any sort of dense people friendly version, like maybe a description on the Wiki or something?... like, so people can get a better idea of what things are about and how they all work and fit together?... (like, in the top-down description kind of way?). I don't think this is for people who aren't prepared to roll up their sleeves and try things out. For a start, learn SmallTalk. It's not hard. Go check out squeak. There are lots of resources to learn SmallTalk. could be. I messed with Squeak some before, but at the time got confused/discouraged and gave up after a little while. My major stumbling block at the moment is understanding OMeta fully. This is possibly the most amazing piece of work I've seen in a long, long time, and there's no easy explanation of it, and no really simple explanation of the syntax, either. There are the papers, and source code and the sandboxes, but I'm still trying to understand how to use it. It's kind of huge. I think perhaps I need to get a grounding in PEGs before I start on OMeta because there seems to be a lot of assumed knowledge there. Mostly I'm having trouble with the absolute, complete basics. Anyway I digress... have you had a look at this file?: http://piumarta.com/software/maru/maru-2.1/test-pepsi.l Just read the whole thing - I found it fairly interesting :) He's build pepsi on maru there... that's pretty fascinating, right? Built a micro smalltalk on top of the S-expression language... and then does a Fast Fourier Transform test using it... my case: looked some, but not entirely sure how it works though. You could do what I've done, and read the papers and then re-read them and re-read them and re-read them... and research all references you find (the whole site is totally full of references to the entire of programming history). I personally think knowing LISP and SmallTalk, some assembler, C, Self, Javascript and other things is going to be incredibly helpful. Also, math is the most helpful! :) ASM and C are fairly well known to me (I currently have a little over 1 Mloc of C code to my name, so I can probably fairly safely say I know C...). I used Scheme before, but eventually gave up on it, mostly due to: problems with the Scheme community (seemed to be very fragmented and filled with elitism); I generally never really could get over the look of S-Expression syntax (and also the issue that no one was happy unless the code had Emacs formatting, but I could never really get over Emacs either); I much preferred C style control flow (which makes arbitrary continues/breaks easier), whereas changing flow through a loop in Scheme often meant seriously reorganizing it; ... Scheme remains as a notable technical influence though (and exposure to Scheme probably had a fairly notable impact on much of my subsequent coding practices). JavaScript I know acceptably, given my own scripting language is partly based on it. however, I have fairly little experience using it in its original context: for fiddling around with web-page layouts (and never really got into the whole AJAX thing). I messed around with Self once before, but couldn't get much interesting from it, but I found the language spec and some papers on the VM fairly interesting, so I scavenged a bunch of ideas from there. the main things I remember: graph of objects, each object being a bag of slots, with the ability to delegate to any number of other objects, and the ability to handle cyclic delegation loops; using a big hash-table for lookups and similar; ... many of those ideas were incorporated into my own language/VM (with tweaks and extensions: such as my VM has lexical scoping, and I later added delegation support to the lexical environment as well, ...). (I chose free-form / arbitrary delegation rather than the single-delegation of JavaScript, due to personally finding it more useful and interesting). I had noted, however, that my model differs in a few significant ways from the description of Lieberman Prototypes on the site (my clone operation directly copies objects, rather than creating a new empty object with copy-on-write style semantics). the current beast looks like a mix of like a C/JS/AS mix on the surface, but internally may have a bit more in common than Scheme and Self than it does with other C-like languages (much past the syntax, and similarities start to fall away). but, yet, I can't really understand SmallTalk code... granted, math is a big weak area of mine: apparently, my effective
