00:00:00 --- log: started retro/12.09.28 01:09:13 --- quit: kumul (Quit: WeeChat 0.3.8) 07:12:24 --- quit: tangentstorm (Ping timeout: 248 seconds) 07:48:07 --- join: kumul (~kumul@adsl-72-50-90-224.prtc.net) joined #retro 09:45:28 --- quit: kumul (Quit: thanks) 11:40:09 I'm curious what lazy evaluation with quotes in retro looks like. :) 12:07:53 I'll try to work up an example tonight or tomorrow 12:09:12 I'll look forward to it. 13:04:12 --- join: tangentstorm (~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net) joined #retro 13:04:20 hey all 13:33:50 * tangentstorm discovers the stock retroImage contains 6969 32-bit cells; suspects it didn't work out that way by chance. :) 13:55:43 tangentstorm: it tends to shrink over time 14:12:41 hi all 14:13:51 hey erider 14:14:32 * tangentstorm may just have the retro mainloop running in pascal... 14:16:04 * erider has be looking at the JVM and believes that ngaro could host more languages 14:19:02 yes it could :) 14:22:13 that's one of the things that drew me to it. you could implement each of the 256 java bytecodes as a word, translate the bytes to the forth word offsets, and execute them directly. 14:23:23 there is 256 words I thought it was less than that 14:23:29 that makes your java bytecode 4 times as big... but then, you could take some kind of compression algorithm that takes repeating chunks produced by the compiler, and assign each chunk its own word too 14:24:24 http://en.wikipedia.org/wiki/Java_bytecode_instruction_listings 14:24:26 when you say java you are talking about JVM right 14:24:37 JVM != Java 14:25:11 ah ok 14:25:43 yeah but most of those are not needed its just let the intel list 14:25:49 yeah, i'm was saying implement those 256 instructions to emulate the jvm, then compress the bytecode and implement each repeating chunk as its own retroforth word. 14:26:11 that would be neat 14:26:39 you could do the same with any other virtual machine... and as you pointed out, there are others that might be better suited than the jvm, even for java 14:26:50 but I bet you could get away with a small subset of words 14:28:11 i'm pretty sure some of the jvm codes are the same except for a number 14:28:54 agreed 14:29:09 yeah like the constants 0..9 are all just pushing literals 14:31:12 and all the type conversion stuff: if you can trust that the bytecode satisfied the real java compiler, you can just ignore those... not sure what to do about floats though :) 14:31:19 yeah you shouldn't need that to push numbers 14:31:22 what language did you have in mind? 14:32:59 where do you begin wow, the jvm has a whole shew of languages but I guess a lisp would be nice or maybe F3 or javafx or whatever they are calling it now 14:34:57 oh i thought maybe you were already working on one ... i always see you in here, but i don't know what you do :) 14:35:46 I have been around this channel for years :) 14:39:06 :) 14:39:59 I have followed crc from the toka days 14:41:40 i don't know what a toka is... i'm kind of a newbie i guess. :) 14:54:46 hrm. well it's not crashing anymore, but all it's doing is an infinite loop that pushes the number 32 onto the stack over and over... guess i've got some debugging to do :) 14:54:53 http://code.google.com/p/toka/ 15:25:32 --- join: kumul (~kumul@adsl-72-50-90-224.prtc.net) joined #retro 15:57:13 --- quit: pqmodn (Ping timeout: 268 seconds) 16:51:08 back 17:11:02 tangentstorm: toka is a language that predates parable and the current retro implementation 17:11:24 it's where I first experimented with types, parsers, and quotations as a language feature 17:11:48 (I no longer work on it, and it's considered discontinued at this point) 17:13:16 :( 17:15:25 lack of time / need. the stuff I was doing with it is possible in retro and parable now, and both are better designed for long term evolution 17:17:39 * erider like the syntax style with the "is" 17:20:05 that can be added to retro; with parable, I try to enforce a more consistent rpn syntax model 17:20:33 crc : sounds like you've been thinking about this stuff for a long time 17:20:47 : is ( quote "name" - ) create @last !d->xt &.word reclass ; 17:20:48 well its forth so just about anything can be added 17:21:10 : is-data ( quote "name" - ) create @last !d->xt &.data reclass ; 17:21:12 and so on 17:21:16 tangentstorm: yes 17:21:56 erider: parable is not forth, and retro is gradually moving away from "mainstream" forth models 17:23:51 is the plan to keep them both going in parallel indefinitely? 17:24:13 hmm 17:24:46 tangentstorm: yes 17:25:26 retro will probably grow a bit closer to parable, but I don't plan to drop either one 17:26:21 I guess you will have to drop the forth from retroforth 17:26:27 what's up with that game-oriented forth that's also on the site? 17:26:37 (one of my goals for the next retro release is to have a suitable parable-source-on-retro runtime enviroment) 17:26:45 tangentstorm: glypher? 17:26:51 that's the one 17:27:22 no updates. I keep it up for historical purposes; afaik no one is using it for anything 17:27:30 i'd pretty much forgotten about it until just now :) 17:27:41 erider: already done, apart from the url's 17:27:52 :) 17:30:05 you should take the "forth" module that makes it more like ANS forth and call that retroforh 17:30:11 er retroforth 17:30:59 make 'retro' the platform, sort of :) 17:32:34 then example/languages/basic could be 'retrobasic' and erider could make 'retrojava' :D 17:33:13 lol /me doesn't like java 17:34:23 I just realized how much the jvm resembles forth 17:34:50 well stack based languages 17:35:06 tangentstorm: retro as a platform is something I'd like to pursue 17:35:33 i've got a pascal-in-forth from like 1980-something as well as several public domain pascal compilers... i've been toying with the idea of a 'retropascal' 17:35:50 platform that you use to create interfaces? 17:36:31 it's a matter of time mostly; in the past, when I dabbled with implementing other languages over retro/ngaro, the support headaches took too much time 17:36:45 tangentstorm: so you wrote a pascal interface in forth? 17:37:37 I had brainf*, c (varient of small-c), and the start of something similar to pilot at one point 17:37:38 erider : nope... i'm currently writing an ngaro implementation in pascal... the pascal-in-forth was from a magazine back in the 80's 17:37:39 yeah specially with large languages 17:38:00 oh 17:38:31 i've transcribed it though and it shouldn't be too hard to port over 17:39:09 https://twitter.com/tangentstorm/status/240072961225281536 17:40:05 the guy that wrote it is a professor now and makes robots. he seems cool, and i suspect he'd be happy to see it reincarnated 17:41:55 that is cool 17:45:25 at some point I want to redo ngaro, with a slightly better instruction set and a cleaner i/o model 17:46:26 I'm glad to hear you say that. :) 17:47:06 crc : have you ever heard of plan 9 from bell labs? 17:49:06 yes. I was never able to get it to run on my systems though 17:49:56 i was trying to find a specific article i remember, but this is basically what i was going to point out : http://en.wikipedia.org/wiki/9P 17:50:32 basically, p9 uses the file system tree for everything 17:50:47 so if you want to read mouse coordinates, you read them from a file 17:50:59 want to write a pixel to the srceen, and you write it to a file 17:51:10 socket connections look like files... 17:51:23 you're kind of in a similar place with ngaro already 17:52:25 how so 17:52:35 * erider doesn't follow 17:52:51 well the way the ports work... there's a standard interface for accessing all the devices 17:54:00 ngaro is a good vm and framework to build on top of like jvm 17:54:01 i was working on this today : https://github.com/sabren/b4/blob/master/ng.ports.inc 17:54:32 every one of those "devices" is simply a function that takes an integer and returns an integer 17:55:13 access to things via a filesystem works nicely. (I've done this with the sqlite bindings, where a daemon handles interfacing with sqlite and provides for queries and such by creating and reading files), and have dabbled a bit with irc using a similar approach 17:55:30 :) 17:55:45 tangentstorm: the problem with ngaro's i/o is that some functions pull/push directly to the stack or memory, so I lack consistency 17:56:31 redoing this will take some work, and won't be rushed, since whatever I change to will be in use for at least a couple of years 17:56:33 i just saw an irc client the other day that make a unix fifo file for every channel... and that was the entire interface 17:56:39 ii ? 17:56:58 well it is hard to do if you have to support more than just unix base systems :( 17:57:00 ... yep! that's it :) 17:57:02 I've used that with retro in the past 17:58:08 erider : you implement it any way you want at the vm level, but then you make it all *appear* the same way at the language level 17:59:01 crc: yes ii 18:01:46 tangentstorm: you were talking about ii right 18:02:27 as for the instruction set... i don't have any complaints, and i think the "default = gosub" is awesome... but for bootstrapping, i'd love to see it boiled down to 8 or 16 core instructions, with the option to implement more if you feel like it or want speed 18:02:36 erider : yes 18:05:19 the instruction set will be pared down a bit, but should be similar overall 18:06:26 ... this whole thing i'm doing is going to be sort of a computer science course... that's the only reason i'm talking about bootstrapping... please don't take it as criticism or anything. :) i want to pare it down to something a student can make himself early on in the course 18:06:44 that's kind of why i'm reinventing the wheel with b4 18:12:59 same thing with the name suggestion, come to think of it... i want to do a chapter on each major language family ( forth, lisp, smalltalk, prolog, pascal/oberon, haskell/ml, joy/factor/retro, data flow languages )... but instead of having to remember that python says "print" and bash calls it "echo", it would use the same words throughout 18:14:12 i'm looking for a "brand", but if using retro would annoy you i've got like 10 others on the list :) 18:14:14 er "retro" 18:17:17 * crc has no problems with it 18:17:56 awesome :) 18:29:24 --- join: arescorpio (~arescorpi@190.17.206.222) joined #retro 18:49:13 * crc should be able to save ui state on the server soon (in parable), so active edits and such will persist across devices/sessions 18:49:54 I'll have to start working on the garbage collector sometime soon 18:51:58 i noticed gc on the toka page, was going to ask about that 18:53:33 crc : are you at all interested in delegating some of this work? 19:00:02 in parable, no; I know what I want to achieve, and how I want to approach it. Just a matter of time (I really don't spend a lot of time coding lately. a few minutes here and there mostly) 19:01:21 with retro, I'm more open. I won't make/accept changes that cause serious breakage, but most things sent to me find their way in 19:01:29 well that's what i was getting at 19:02:02 not "give someone cart blanche to do it their way", but "let someone try to do it the way you want it done" 19:02:50 If someone works on something, I'll be happy to review and include if it seems ok 19:08:46 so some of the easy things at the vm level are fleshing out the various ngaros... maybe making a test suite for them, to make sure they act the same way... and you'd mentioned wanting a coffeescript port. 19:09:42 most of the vm code is from others :) 19:10:13 a test suite would be a big help, and I definitely want a coffeescript port 19:10:30 at the language level, you were talking about the flattened dictionary idea... and someone could be working on a proposal for the new port/io system 19:10:51 the js was a hack job, adapted from the C and Java implementations, written as my first large thing in javascript 19:10:58 yes 19:10:59 what else would be on your wishlist, but kind of not in your way? 19:11:50 the library needs expansions 19:12:04 i have one gripe : the colors / palettes are diffferent between the canvas an the text 19:12:42 can you be more specific? :) 19:12:45 with regards to the core language, some big things are prefixes and string handling (currently built up at several points, layering over earlier pieces of code) 19:14:11 there are things like the hashing library, which only provides one hash implementation, and the calendar library could be made much more useful 19:16:08 tangentstorm: re: colors, a unified palette would be helpful 19:16:45 I don't do a lot with color though, so it's not something that I've tried to address 19:17:34 how fleshed out is that editor example? honestly, i'm not even sure how to run it :) 19:34:07 the block editor? 19:36:57 the block editor is complete; before adding files to retro, I used it a lot 19:37:24 the doc{ }doc block has a usage guide (embedded in ReST format, at the end of the file) 19:39:16 --- quit: kumul (Quit: WeeChat 0.3.8) 19:41:01 cool. i'll have to read it again. i've printed out the docs, but if you can't tell my brain's a little scattered most of the time :) 19:41:45 not a problem :) 19:52:25 ok... so i'm reading the contribution page and i've got a patch to submit. 19:53:10 i'm totally new to bazaar. do i make a new branch for each submission? 19:55:22 that would work 19:55:51 alternatly, make one branch, and let me know when to pull from it 19:56:25 I personally like making a branch for new features / groups of related features 19:57:48 (for instance, the pascal vm. setup a branch, and push your changes to it. I can pull as needed into my branch, and repull as you make changes) 20:06:38 okay, so it's pretty much a matter of policy then. cool. well, this first one's for the docs, and i've also got an emacs mode to contribute... the pascal stuff's going to be a while still :) 20:18:02 i think it worked. how bzr. 20:22:25 it worked; I've merged the changes 20:39:51 cool :) 20:40:44 are any of you guys on reddit? 20:44:07 i was asking about delegating because http://www.reddit.com/r/learnprogramming/ has a mentoring community, and i think the various ngaro backends would let a lot of different people contribute. 21:25:51 --- quit: arescorpio (Read error: Connection reset by peer) 23:59:59 --- log: ended retro/12.09.28