00:00:00 --- log: started retro/12.10.06
01:51:53 <tangentstorm> writing some docs here. anyone know what # means in a stack comment?
01:52:36 <tangentstorm> i can't tell if it means number or counted string ( for the word # in the meta compiler )
03:36:31 <crc> tangentstorm: which function has # in a stack comment?
03:37:37 <crc> # in the metacompiler just compiles a literal from the stack into a target definition. 
03:38:28 <crc> 100 #    <same as>  lit, 100 m,
04:02:51 <tangentstorm> crc : yeah, i must have screwed it up moving stuff around. thanks for answering though
04:23:32 <tangentstorm> very early draft of the "b4" concept applied to retro, if anyone's curious : https://github.com/sabren/b4/blob/master/ref/topdown-retro.org
04:23:43 * tangentstorm is off to bed
08:36:32 <crc> https://gist.github.com/3833902 is the start of a new overview document for Parable
09:06:03 --- quit: obobo (Quit: bye)
09:07:38 <oPless> port 5 … queries for −16, and −17 == −5, and -6 ?
09:09:25 <oPless> or just the total size of the data/address stack ?
09:31:13 <tangentstorm> oPless : looking at retro.c, -16 returns STACK_DEPTH, which is a constant (128 for that vm)
09:31:47 <tangentstorm> -17 is ADDRESSES=1024, probably the initial ram?
09:32:14 <tangentstorm> -5 and -6 are the current number of values actually on the data and return stacks
09:32:40 <tangentstorm> crc : "It is also possible to export a function, and all of its dependencies for sharing with others." handy!
09:33:08 <tangentstorm> you ought to expose that in the UI as well... like a function explorer
09:35:15 <tangentstorm> I wanted to automate something like that for the article I posted but I'm not sure how to do it yet because of macro expansion
09:38:19 <tangentstorm> Once I finish walking the tree here I'm going to try adding an auxilliary dictionary to store the comments, formatting, and unexpanded macros from each definition
09:38:30 <oPless> tangentstorm, which VM is this?
09:42:52 <tangentstorm> oPless: I was looking at the code for vm/complete/retro.c from the latest version on launchpad
09:45:17 <oPless> ok
09:45:27 <oPless> I'm looking on google code.
09:48:47 <oPless> looks like I chose the correct definition anyhow :D
09:48:56 <oPless> cheers tangentstorm
09:48:59 <tangentstorm> oPless: I'm not sure how often they sync, but i doubt that retro.c's been changed in ages. it's pretty stable
09:49:13 <tangentstorm> :)
09:49:17 <oPless> I was looking at the experimental ones
09:49:36 <oPless> I didn't realise complete had sourcefiles in there
09:49:55 * oPless is writing a plug-in device based C# version
09:50:24 <oPless> very very slowly apparently :)
09:50:32 <tangentstorm> haha :)
09:50:52 <tangentstorm> yeah, i've been working on a pascal port bit by bit for the past month or so
09:51:01 <oPless> though the framebuffer implementation seems to have vanished.
09:51:39 <tangentstorm> in the retro codebase? I think it's got SDL in the name
09:51:46 <oPless> oooh, that's right
09:51:51 <tangentstorm> AFAIK the main one with graphics is the javascript version
09:54:23 <tangentstorm> crc : "And descriptions can be added via describe:" yay. parable's looking pretty slick. :)
09:57:11 <oPless> ah, found the sdl version - excellent.
09:57:32 <oPless> being able to abstract all this away is good.
09:58:15 <tangentstorm> what are you plugging in? :)
10:00:28 <oPless> well, I have a device interface, and each device object can manage 0..n ports
10:01:03 <oPless> but the DeviceInfoDevice needs to talk to the other devices to find their capabilities
10:02:21 <tangentstorm> like a plug-n-play kind of thing
10:02:31 <oPless> so if someone else decide to implement some other device (tcp ports, file system, banana hoops, etc) they just write a new class to deal with them
10:02:34 <oPless> ja
10:03:31 <oPless> though I'm a little concerned that I have no tests that I can throw at my VM to ensure that it's correct
10:03:34 * tangentstorm is suddenly thinking about generic usb access
10:04:12 <tangentstorm> oPless: I've been dealing with the same issue
10:04:29 <tangentstorm> or rather putting off dealing with it
10:04:48 <tangentstorm> there are some tests for retro, though, and you can run those
10:05:58 <tangentstorm> under /test/
10:06:04 <oPless> the memory system is nice though, I can set up main memory and data/address stacks dynamically
10:08:19 <crc> -17 should be the max depth of the address stack IIRC
10:09:13 <tangentstorm> oh yeah. duh :)
10:10:06 <tangentstorm> i guess i think of it as the "return" stack
10:11:50 <tangentstorm> oPless, crc : you guys ever look at cucumber/gherkin? it's a testing language. https://github.com/cucumber/cucumber/wiki/Gherkin
10:12:47 <tangentstorm> what's interesting about it is that all the tests are defined in terms of the domain, completely decoupled from the implementation language
10:14:36 <tangentstorm> so you can say   "GIVEN the stack is empty / WHEN we run: 1 2 3 / THEN the stack contains: 3 2 1 "
10:17:42 <tangentstorm> Then you just give it a bunch of regexps on the backend and show the test runner what to execute for each one, so that's language independent too.
10:18:52 <tangentstorm> I think it makes a lot of sense for retro, given the large variety of virtual machines lying around.
10:20:33 <oPless> sounds cool.
10:20:45 * oPless returns to real life
11:22:20 <docl> interesting
11:22:45 <docl> I was just thinking it would be interesting to have generic usb support for retro.
11:26:41 * tangentstorm plugs in his FPGA, printer, phone, eeg machine, gamepad
13:39:32 <crc> tangentstorm: docstrings like parable has will be coming to retro, along with the rpn style function declarations
13:40:34 <crc> and function export/dependencies is only accessible via the parable ui at present
14:01:14 <tangentstorm> crc : in that case, would it help if I added the doc comments to kernel.rx as i go along here? that would actually make my life easier too
14:03:39 * tangentstorm decides to try it
14:58:18 <crc> I setup a branch with an image with docstring pointer field in the dictionary headers (lp:~crc-x/retro-language/docstrings)
14:59:24 <crc> for space reasons, I can't include the docstrings by default. I'll put them into an easily loadable module for use on non-embedded systems
15:02:58 --- join: Mat2 (5b4085c5@gateway/web/freenode/ip.91.64.133.197) joined #retro
15:03:04 <Mat2> hello
15:03:31 <crc> hi Mat2 
15:03:43 <Mat2> hi crc
15:04:46 <Mat2> hope you enjoy the weekend
15:06:48 <crc> I'll try to enjoy the rest of it. I just got home from work :)
15:09:47 <crc> tangentstorm: I merged in the documentation updates you've pushed
15:13:58 <Mat2> i've compared some basic vector operations based upon arithmetic and SSE saturated arithmetic just to conclude that later implementation shows no advantage at all :(
15:14:42 <Mat2> ^integer arithmetic I mean
15:17:43 <tangentstorm> crc : you don't have to include them in the image to include them in the source. we can make them sort of a conditional comment
15:18:15 <crc> tangentstorm: if you can implement that, I'd be more than happy to include it
15:18:30 <crc> embedded documentation is something I've missed for too long
15:19:03 <tangentstorm> Mat2: heya. sorry to hear that... maybe you should look for an application that can take advantage of such things... like graphics filters
15:20:48 <Mat2> tangentstorm: It's sad, the SSE instructions seem to be of to specific purpose for these task, I miss Altivec for vm development
15:22:12 <tangentstorm> Mat2: i had always been more interested in using the SSE registers as ram, not so much in using the SSE instruction set
15:26:40 <tangentstorm> crc: the easiest way to do this would be to adopt a special syntax for stack comments. I was thinking :( ) ... And then maybe :"..." for docstrings
15:28:02 <tangentstorm> they can just revector to (  and something like ( that looks for " and discards it
15:28:43 <tangentstorm> maybe :" ": so we can put quotation marks inside?
15:30:25 <crc> something like that could work
15:30:33 <crc> I'll think on how to implement this
15:32:59 <tangentstorm> i'll put /:" in the source since it's distinguishable as an end marker but still works with strings. it's ugly but search and replace can fix it later
15:33:24 <crc> sounds good
15:33:56 <Mat2> get some sleep, ciao
15:34:02 --- quit: Mat2 (Quit: Page closed)
15:41:19 <tangentstorm> what is rune? docl has a branch of that too
15:41:37 <crc> from github?
15:43:41 <crc> on occasion I have been implementing small clones of unix tools with no gpl dependencies, and smaller than the modern codebases. it's part of an ongoing and gradual process to eventually get a minimalistic userland
15:44:09 <tangentstorm> don't suppose you have tsort in there? :)
15:44:25 * tangentstorm wants a retroshell
15:44:31 <crc> no
15:45:07 <crc> cat, ls, sh, wc, a text editor similar to pico/nano
15:45:31 <crc> I had a grep implementation, but lost the source before I started using version control :(
15:45:36 <saper> ed(1)
15:45:42 <crc> no ed
15:46:26 <tangentstorm> ed's probably hidden away in your pico/nano though , except for the regexps
15:46:50 <saper> pico/nano are curses-based
15:48:13 <tangentstorm> saper: yeah, but they're still editing lines of text
15:48:55 <crc> tangentstorm: I never felt a desire to implement ed
15:50:38 <tangentstorm> you almost can't not implement it if you make an editor, especially in forth. i bet it's mostly there, just with different words for the commands
15:51:02 <crc> the rune code is all in c, not forth/retro
15:51:07 <tangentstorm> oh
15:51:53 <crc> I started implementing some bits in retro (under examples/util)
15:51:58 <tangentstorm> well i bet there's an ed in examples/editor.rx :)
15:52:36 <crc> there are crude implementations of cat, head, wc, and a 'grep' with no regex
15:52:41 <tangentstorm> it's more block/buffer oriented, though.. hrm..
15:52:44 <tangentstorm> yeah, i saw those
15:54:28 <tangentstorm> oberon has pretty amazing text edititing features. i'm probably going to pull most of my editing stuff from there
15:55:21 <crc> oberon was interesting. I used it briefly (system 3, native) on my original computer (an ancient 80386 system)
15:55:21 <tangentstorm> anyway.. do i need to make a separate working directory to fork your documentation branch, or can i somehow merge it into my docwork branch?
15:57:27 <tangentstorm> i haven't been able to use it seriously. I studied the book, but there are little things in the interface that drive me nuts and i don't know how to fix (like the font)
15:58:03 <crc> bzr merge lp:~crc-x/retro-language/docstrings
15:58:06 <tangentstorm> but the ideas are awesome.
15:58:10 <tangentstorm> ah thanks!
15:58:12 <crc> bzr commit -m "merge upstream"
15:58:15 <crc> that should work
15:58:29 <tangentstorm> huh
15:58:32 <tangentstorm> cool
16:00:58 <tangentstorm> oh... i have a patch for The_Ngaro_Virtual_Machine.rst too, but it's more than just typos and i'm not sure it's 100% correct. 
16:01:10 <tangentstorm> It's about the Port 0 / OUT / WAIT stuff... 
16:01:25 <tangentstorm> If I check it in can you cherry-pick commits?
16:01:37 <tangentstorm> ( in case you don't want it i mean )
16:01:49 <crc> I've never done a cherry pick 
16:02:54 <crc> tangentstorm: push it. I can always revert to an earlier copy if needed
16:03:03 <tangentstorm> will do
16:08:39 <tangentstorm> ok... merged and pushed. that wasn't so bad.
16:26:26 <crc> from a quick read that looks ok, so I'll pull it into the main branch later tonight
16:37:42 <tangentstorm> crc : cool.
17:12:39 <tangentstorm> hrm.. the big "initial dictionary" block that copies everything over in kernel.rx is pretty, but i'm thinking it would make more sense to leave a placeholder class up front as each word is defined, and then just do all this in a loop
17:24:36 <crc> I'm not sure I follow
17:25:44 <crc> create headers as we go, and then patch the headers later?
17:25:47 <docl> tangentstorm: you mean in meta.rx? I'm confused too
17:26:14 <docl> (probably for different reasons)
17:26:31 <crc> part of the issue too is how to avoid namespace conflicts between the new definitions and the ones in the original image
17:27:24 <crc> (I should note that the overall structure of kernel.rx hasn't changed drastically since the early 10.x days, before the metacompiler was added. I mostly adapted the original source for the metacompiler, with as few changes as possible)
17:31:21 <docl> cool, just noticed the old style of "if" macros are defined in the metacompiler.
17:31:42 <docl> I kind of miss those.
17:34:00 <crc> docl: I don't. I've grown to prefer the more rigid syntax/structure enforced by quotes
17:34:30 <crc> (though that's probably due to having to explain the special cases introduced by the older forms one too many times)
17:34:30 <docl> probably just nostalgia on my part. the quotes are actually more readable.
17:34:40 <docl> :)
17:34:57 <crc> I can't implement the old style in parable at all (no jumps, no macros)
17:35:22 <crc> consistency = less support headaches = more time to work on things I find interesting :)
17:36:21 <docl> well, there's that :)
17:39:26 <docl> I'm starting to get used to the new getc/putc/gets/puts syntax for IO.
17:40:27 <docl> wait, there's no gets
17:40:34 <docl> must be thinking haskell.
17:41:39 <crc> gets would be similar to accept I think
17:42:02 <docl> yeah. or maybe more like the quotation mark prefix.
17:49:23 <crc> I've thought about renaming accept to gets
17:49:57 <crc> it'd be trivial, but would break a fair amount of library code + examples. Though a search/replace would take care of that...
17:56:57 <docl> hmm. my default assumption is that gets would leave the string on the stack. but we probably don't actually need a command like that.
18:03:40 <crc> that would be similar to accept
18:03:59 <docl> accept just puts it in the tib and returns nothing, right?
18:04:03 <crc> I suppose a 'gets' would return a pointer to a string, in the rotating string buffer 
18:04:07 <crc> docl: yes
18:05:04 <docl> so it's more efficient and has less implementation complexity than my hypothetical gets.
18:05:30 <docl> the cost is that it is less intuitive for newbies who now have to learn about the tib and so forth.
18:05:52 <docl> and how to save strings to a safe area of memory.
18:06:03 <docl> there's a rotating string buffer?
18:07:48 <crc> tempString adds strings to a rotating buffer of temporary strings
18:07:58 <docl> cool
18:08:09 <crc> this was added a few versions back
18:08:09 <docl> I guess I'm ok with renaming accept to gets despite the slight counterintuitiveness that nothing would be left on the stack and you have to specify a delimiter.
18:08:42 <docl> people would get used to 32 gets tempString
18:08:45 <crc> : gets  ( character:delimiter - string:temporary )  accept tib tempString ;
18:09:18 <docl> oops, forgot to specify tib
18:09:34 <crc> this would possibly be better, as it leaves the primitive function alone
18:09:47 <docl> yeah
18:09:58 <crc> for 32 ...  we have getToken  :)
18:10:04 <docl> ahh :)
18:13:30 <docl> yeah, that definition of gets would be great.
18:16:37 <docl> then you could introduce gets first to newbies (after getToken maybe), and accept as it's primitive tib-using cousin.
18:21:54 <crc> or just ignore accept, unless dealing with someone delving into the internals
18:24:03 --- join: kumul (~kumul@cvx-ppp-66-50-130-239.coqui.net) joined #retro
18:26:10 <docl> yeah
18:32:21 <tangentstorm> i would expect a gets to wait for a newline, as opposed to getToken
18:33:09 <tangentstorm> maybe not. i don't know
18:33:12 <docl> I would call that getLine
18:33:38 <tangentstorm> yeah, nm..
18:34:39 <tangentstorm> the table i was talking about earlier is the "initial dictionary" area in kernel.rx
18:34:57 <docl> ah, yeah I eventually figured that out
18:35:07 <crc> tangentstorm: newlines are an issue since they are remappe to spaces normally
18:36:22 <tangentstorm> i've chopped up the Core_Functions.rst file and I'm looking to plug in doc comments for each word.
18:37:33 <tangentstorm> For what I want to do, the code would be stored in a database, so i don't have any particular preference where the docstrings go in the source code.
18:38:03 <tangentstorm> i was thinking they could just be wrapped in those special quotes, and part of their job would be to update the last definition
18:38:05 <docl> : getLine ("-$ ) remapping off 10 accept tib tempString remapping on ;
18:39:05 <tangentstorm> but then i saw this table, and i'm thinking that what i'm doing is going to conflict with what it's doing
18:39:41 <crc> : get:line ( "parsing" - string )  remapping [ remapping off 10 gets ] preserve ;
18:40:17 <docl> crc: new style?
18:40:30 <crc> docl: preserve combinator here, since we don't know the original state, and should probably maintain it to avoid potential issues if a user has changed it
18:40:55 <docl> oh yeah
18:41:32 * docl needs to get more into the habit of using combinators
18:42:29 <tangentstorm> crc : is the colon in get:line just a convention you're looking to install?
18:43:15 <docl> not having to capitalize the L would be nice
18:46:53 <crc> tangentstorm: sorry, it's a convention I'm using in parable
18:47:09 <crc> docl: case insensitivity is coming in 11.5
18:47:22 <tangentstorm> crc: yeah, when i saw it, i thought "that looks more like parable code"
18:48:02 <docl> cool
18:48:43 <tangentstorm> can i assume that the 3 of us are currently the bulk of the active retro userbase?
18:49:12 <crc> I'd say so
18:49:24 <tangentstorm> hrm
18:49:38 <crc> there tends to be me and docl, and others coming and going over the years
18:50:28 <crc> as with parable, I keep working on it because it meets my needs. Others jump in when they want, or not. I've long stopped worrying about it.
18:51:56 <crc> the ngaro vm tends to get more attention than retro itself though
18:52:10 <tangentstorm> It's just... I'm looking to build something kind of big here, and drive a lot of attention toward what I'm doing.
18:52:59 <tangentstorm> ngaro is really really well designed, and it has the cross platform aspect. that's what drew me to it.
18:53:30 <docl> hmm. what would we do if we became... popular?
18:53:31 <tangentstorm> retro has kind of a steep learning curve... not because it's inherently hard or anything... it's just... not quite as approachable
18:53:55 <tangentstorm> a lot of it is just the forthyness of it all
18:54:53 <tangentstorm> the core dictionary has 230 words and it's hard to remember them, especially when there in one long text or html file with no navigation
18:55:07 <crc> tangentstorm: I would love to see other languages running on ngaro (or something similar)
18:55:09 <tangentstorm> i mean it's hard to learn them all up front
18:55:14 <crc> true
18:55:58 <tangentstorm> that's why i've been pestering you about learnability and all that.. and i think you've been a tremendous help.
18:56:24 <crc> the lack of documentation comes down to time. given the small amount of interest in retro as a language, I've not developed any real tutorial material. Ngaro gets more interest, but the people using it tend to know where they want to take it already.
18:56:26 <tangentstorm> there's a ton of great information here, it's just not visible
18:57:11 <tangentstorm> crc: ngaro's something i can keep in my head. One of the main reasons I picked it was it only had 32 opcodes.
18:57:25 <tangentstorm> I'm with Mat2 on trying to bring it down to 16
18:57:57 <crc> I chose the 32 based on code I had written in Forth previously, and some performance tests
18:58:13 <tangentstorm> retro is in an odd place, because a) the audience of people who even know what forth is is very small these days
18:58:53 --- join: obobo (~chatzilla@dyn-dsl-pt-76-75-103-171.nexicom.net) joined #retro
18:59:03 <docl> yeah
19:00:14 <tangentstorm> b) for those that want a forth, there's ANS forth ( with books and legacy code and even the occasional job ),
19:01:07 <tangentstorm> factor ( which takes the strongly functional approach, had quite a bit of attention in certain circles ( there's an hour long google tech talk up on youtube, for example )
19:01:39 <tangentstorm> colorforth, which is completely crazy and unusable but has chuck moore and green arrays behind it
19:01:55 <tangentstorm> ... and a bunch of other small, roll your own forths
19:03:19 <tangentstorm> my plan was to roll my own even before i found retro
19:03:58 <tangentstorm> but... well, i came for the virtual machine and stuck around because it's actually really good.
19:05:14 <tangentstorm> retro's got a nice moderate style that's somewhere between old school forth and factor
19:05:23 <tangentstorm> and it's small
19:05:42 <tangentstorm> and it's hooked up directly to all those cool ports on ngaro
19:06:35 <crc> it's not small enough IMO. I want to pare down the core language, and streamline things. but that'll break things, and I need time to decide how to deal with things better.
19:06:39 <tangentstorm> i think if you decided to compete on documentation and learnability, it could actually take off and be kind of popular.
19:07:03 <tangentstorm> and by you i mean me ... ;)
19:07:11 <crc> :)
19:07:12 <docl> :)
19:07:19 <tangentstorm> but
19:07:55 <tangentstorm> if i teach 10 or 20 people how to use it, and it's a completely different language each release, that's not so good
19:08:29 <tangentstorm> and if i teach 1000 people to use it and that's going on, then all you'll here is "retro sucks" :/
19:09:37 <tangentstorm> it's just kind of dawning on me now that you've just kind of been making it whatever you want all this time.
19:09:51 <tangentstorm> i don't want to take that away from you if that's what you want
19:10:57 <crc> generally speaking, retro11 hasn't changed much throughout the releases. Not as much as prior versions by far. I am at a point where I need something mostly stable.
19:11:05 <tangentstorm> i guess i've been seeing "retro" as kind of an existing, stable entity
19:11:19 <tangentstorm> yeah
19:11:34 <crc> some things (embedded docstrings, case insensitivity) can be added without breaking anything
19:11:43 <tangentstorm> yeah.. was just about to say that
19:12:35 <tangentstorm> but... like... when you mentioned that the chains might be going away in favor of parable's data structure... that would kind of break things for me
19:12:40 <crc> it won't change drastically anytime soon (e.g., a retro12 would be maybe 2-3 years out at this point)
19:12:53 <crc> chains aren't being dropped from retro11
19:13:02 <tangentstorm> oh. whew :)
19:13:44 <crc> I made a promise with retro11 to keep things compatible for at least a few years. I don't want to break that
19:13:54 <tangentstorm> excellent
19:17:37 <tangentstorm> i guess that particular point was my main concern... it doesn't sound like there's really a problem here at all for me
19:17:59 <docl> yeah it had me a little worried too
19:18:06 <tangentstorm> what about for you? like docl said... what would you do if retro became popular? :)
19:19:27 <crc> It used to be more popular. I would spend my evenings helping people learn to use it. But back then it was changing too fast. Minor releases would require rewrites of large pieces of code.
19:19:52 <crc> I have time to spend in helping users, and would like to see it get more use.
19:20:58 <tangentstorm> :)
19:21:01 <tangentstorm> cool
19:22:14 <tangentstorm> on the other hand... things that are fun in moderation can turn into a nightmare if they get TOO big
19:24:56 <docl> well, if it gets big there will in theory be ways to monetize that. perhaps crc can form a company and hire staff to support it.
19:25:40 <tangentstorm> i ran (run?) a little web hosting company for 10 years and it kind of just grew beyond my ability to manage it... the stuff i'm doing now is sort of the result of me asking the question "what's preventing me from getting my ideas out into the world on a grand scale?" and then following that chain of thought down the rabbit hole for a year :)
19:26:21 <crc> tangentstorm: if I had to guess, it'll be a while before it gets big enough that it becomes a nightmare
19:26:28 <tangentstorm> haha
19:27:10 <tangentstorm> yeah, that's true... things grow pretty slowly and you don't notice it becoming unmanageable
19:27:57 <crc> I'd hope that if it becomes popular enough, others would step up to help deal with issues that arise
19:29:17 <tangentstorm> i realize it's not going to be java overnight or anything, and there's every chance in the world i'll fall flat on my face and it won't go anywhere
19:31:30 <tangentstorm> but i do plan to have ongoing market campaigns (including a big kickstarter launch), a training / mentoring program ( the reddit.com/r/lpmc group i mentioned a while back ), and a rather big project to hack on ( oberon )
19:33:27 <tangentstorm> also i really want to do something like arduino with the greenarrays chip... hence the interest in the concurrency stuff
19:33:36 <crc> I'll help where I can
19:34:08 <crc> I have no experience with concurrency, apart from a little playing with the golang implementation of ngaro
19:37:14 <tangentstorm> i'm not a huge expert on it either... but they have a really cool machine... 144 forth-based stack machines arranged in a grid smaller than a postage stamp and it only costs $20
19:38:11 <tangentstorm> one of the public domain pascal compilers i have is concurrent ( superpascal )
19:38:47 <crc> the greenarrays boards are for sell?
19:38:55 <tangentstorm> yeas
19:39:08 * docl ponders 100+ ngaros on a chip talking to each other
19:39:30 <tangentstorm> you can only buy 10-packs for $200 directly from them
19:39:35 <crc> last I saw the boards were over $400
19:39:39 <tangentstorm> or you can buy their eval board which is $450
19:39:54 <crc> I can't afford $450 currently :(
19:39:58 <tangentstorm> me either
19:40:29 <tangentstorm> the $400 board is already soldered together and has ports for all kinds of things on it
19:40:59 <tangentstorm> but you can buy the individual chips for $20 resale from another company
19:41:19 <tangentstorm> the greenarray guys are all working for free and living off their savings... or at least were this time last year
19:41:47 <tangentstorm> the only reason they don't sell individual ones is that they don't have the staff
19:42:27 <tangentstorm> but this other electronics shop will sell you the individual chip
19:42:52 <tangentstorm> you have to solder it yourself, though... with the board it's like $35
19:43:44 <docl> I wonder how hard it would be to make a custom chip and then put it on a modified USB stick.
19:45:23 <docl> tangentstorm: are you thinking of making a retro optimized chip, or using greenarrays with retro?
19:45:46 <tangentstorm> http://www.greenarraychips.com/home/documents/budget.html
19:45:59 <tangentstorm> man.. their site is terrible to navigate 
19:46:29 <tangentstorm> docl: i don't know ... i'm not an electronics guy at all, so it's completely new to me
19:47:13 <docl> probably best to start with an fpga
19:47:56 <tangentstorm> yeah i have a papilio one i haven't opened yet that i want to learn about
19:49:02 <tangentstorm> the greenarray cpus are all very very small... if i recall, the data and return stacks are limited to 8 items each, not counting nos, tos, and "R" (tos for the address stack)
19:49:31 <docl> http://www.arrownac.com/offers/altera-corporation/bemicro/
19:49:56 <docl> apparently they make fpga usb sticks
19:50:14 <tangentstorm> but, besides colorforth, they also have a virtual machine that combines several cpus and runs ansi forth, so... maybe a retro vm on that platform is possible?
19:51:17 <docl> looks like they're $80
19:51:22 <tangentstorm> that guy impomatic does a lot of work with hardware. ( he makes itsyfoth )
19:51:28 <tangentstorm> er itsyforth
19:52:46 <tangentstorm> docl: huh. i hadn't seen that one... papilio's an arduino-style board that you can connect to over usb
19:54:12 <tangentstorm> anyway, impomatic told me about a guy he thought might be interested in and capable of doing the legwork on a small, cheap, dev board
19:55:47 <tangentstorm> arduino, rasberry pi, and papilio all seem to be doing well... and there's a gap in the market for an easily approachable parallel programming system on that scale
19:58:15 <tangentstorm> oh.. last thing: i wrote a python compiler for the parrot virtual machine a few years ago. it mostly worked, until i ran into the limitations of parrot's support for objects ( which hadn't been written yet )
19:59:01 <docl> cool
19:59:07 <tangentstorm> anyway, there is really no viable, supported way to run python in a browser, or in a restricted environment at the moment
20:00:11 <tangentstorm> parrot's a complete mess inside. i think ngaro's a much better platform to build on.
20:00:16 <docl> that's a niche. lots of python code out there.
20:00:21 <docl> (and coders)
20:00:29 <tangentstorm> yes, and students
20:01:49 <tangentstorm> so... i guess part of my evil plan is to kind of funnel all of those things into one place, and retro/ngaro kind of seems to be that place
20:02:30 * docl likes this plan.
20:03:00 <tangentstorm> well, thanks :)
20:04:31 <tangentstorm> anyway, just kind of a heads up / something to think about.
20:06:55 <tangentstorm> er, but also a chance to say: please steer the horde of newbies elsewhere, or call it something else
20:14:02 <docl> tangentstorm: are you familiar with retro's parent project, tunes?
20:14:05 <docl> http://tunes.org/
20:15:36 <crc> just to clarify; retro has not been a part of the tunes project since before I took over as developer/maintainer
20:15:48 <docl> ahh
20:16:10 <tangentstorm> sounds familiar.. looking
20:16:13 <docl> so it's kind of a branch? or should we think of it more as a separate thing entirely?
20:17:05 <crc> docl: mostly retro2 was considered for use as the LLL part of tunes. This was scrapped when Tom Novelli started on v3 and v4
20:20:25 <tangentstorm> pretty sure i've seen references to tunes.org before, but the actual site is new to me.
20:20:46 <docl> tangentstorm: anyway the idea of making this universal super-system is not new to the community that retro is part of. you may be able to fan some old flames and get people on board who once were distantly involved.
20:21:46 <docl> Tom Novelli works in javascript/nodejs these days. the idea of implementing js in ngaro might hold some appeal.
20:23:33 <tangentstorm> the thought of doing that had crossed my mind
20:24:12 <tangentstorm> huh. thanks for telling me this...
20:25:44 <tangentstorm> re fanning the flames : yeah, that nostalgia for the younger days of computing is definitely part of the vibe i wanted to shoot for with all this
20:26:04 <docl> :)
20:26:20 <tangentstorm> not so sure i want a universal super system though, so much as a "personal" system...
20:26:45 <docl> point taken
20:26:50 <tangentstorm> one of my inspirations was http://www.jvuletich.org/Cuis/Index.html
20:27:17 <tangentstorm> it's basically squeak smalltalk, except with about 50-60% of the junk removed
20:27:26 <tangentstorm> maybe even 70-80%
20:30:04 <tangentstorm> he pointed out one of the essays from the early days of smalltalk and about the idea that the entire system should be understandable to a single person
20:30:33 <docl> interesting
20:31:01 <tangentstorm> with java or whatever.. you need a platform that can handle every possible situation
20:31:09 <tangentstorm> because that's corporate world stuff
20:33:42 <tangentstorm> i think part of the reason ngaro attracts more attention than retro is that while they're both very small and flexible and hackable... ngaro feels like something you could draw out on a page or two
20:34:30 <tangentstorm> i think that retro's probably like that for the two of you ... i'm starting to see how simple and regular it is myself, but for whatever reason it was just harder to get there
20:35:13 <tangentstorm> but yeah. small and hackable and understandable. there's a need for that.
20:35:33 <tangentstorm> ... sorry i keep rambling all the time :D
20:36:26 <docl> no problem :)
20:37:32 <docl> yeah, you're learning this a lot faster than I did, that's for sure
20:38:25 <tangentstorm> well... this is kind of my "job" at the moment
20:39:05 <docl> retro seems to enforce a kind of discipline. leaving out extra stuff and just focusing on making the machine do what you want it to.
20:39:07 <tangentstorm> also i had you guys :)
20:39:42 <docl> :)
20:41:08 <docl> I kinda get a kick out of explaining things. getting people's minds to click in understanding.
20:42:45 <tangentstorm> anyhow... in the interest of actually getting something done here... i'm thinking the implementation for :" ": should be pretty much exactly like doc{ }doc when the docstrings are turned off
20:43:26 <tangentstorm> docl: yeah, i've been thinking about recruiting you for the /r/lpmc stuff... 
20:44:19 <tangentstorm> that group started because every other day on /r/learnprogramming , people were saying " i want to contribute to an open source project, but i don't know how"
20:45:25 <tangentstorm> so these guys decided to put together something to help ease the transition into working on open source projects, through mentoring
20:45:50 <tangentstorm> but there's not a lot really happening
20:46:21 <tangentstorm> a bunch of projects on the list, but none of them are really active
20:47:44 <tangentstorm> or i guess most of the mentors are just doing their own projects... they have an organization and a purpose but they don't really have a plan yet
20:50:27 <tangentstorm> anyway... at some point, if you're up for it, i'll probably write an article about how you've helped me and maybe ask you some questions about how annoying i've been and whatnot, and also what it was like for you getting involved with the project, etc.
20:50:44 <tangentstorm> lead by example ;)
20:51:51 <docl> sure
20:53:03 <tangentstorm> cool :)
20:54:56 <docl> I kind of see what you are saying about retro being an example of your paradigm, "personal programming" -- start very low level and build your way to something cool, your way.
20:56:23 <docl> that's kind of what I like about retro. I know exactly what I'm doing and why at every step.
20:56:39 <tangentstorm> yeah
20:57:02 <tangentstorm> yeah.. that should be the slogan :)
20:57:44 <docl> of course, all kinds of stuff used to mystify me. why are linked lists and tuples so common, instead of something more human-friendly?
20:58:10 <docl> but after playing around with it and trying to come up with something better, I ended up reinventing things.
20:58:34 <docl> then I'd ask crc if this or that would work, and he'd suggest a much more concise way of doing the exact same thing.
20:58:48 <docl> lightbulb!
20:59:18 <tangentstorm> :)
20:59:36 <docl> but if I hadn't tried doing it on my own I wouldn't have understood why it was being done that particular way.
21:00:01 <docl> I could maybe have copied and pasted, but I wouldn't know what the magic symbols mean... you know?
21:00:11 <tangentstorm> yes very much
21:00:53 <docl> how can people understand java if they've never tried to implement a type system?
21:01:03 <docl> or an object system?
21:01:03 <tangentstorm> for me it was turbo pascal... because i had it, and really nothing else around to show me how to do anything.
22:39:53 <docl> I'm tempted to try to write a file system in retro.
22:40:08 <docl> vocabs are like dirs
22:40:27 <docl> contain other "files"
22:41:04 <tangentstorm> very true
22:41:16 <docl> system files go in some places, user modifiable stuff in others
22:41:42 <docl> that would tie into our proposed system of who gets to see what
22:43:03 <tangentstorm> hmm
22:43:37 <tangentstorm> the thing you need for a file system is kind of similar to what you need for an editor
22:44:04 <tangentstorm> it's a lot like chains, actually
22:44:09 <docl> yeah exactly
22:44:21 <tangentstorm> but i mean for the files themselves
22:44:59 <tangentstorm> like if you allocate space in the image for files, and then the file grows
22:45:23 <docl> put a link to the next um sector?
22:45:26 <tangentstorm> but like.. you've already added another file in the position it would grow into 
22:45:31 <tangentstorm> yeah
22:46:22 <tangentstorm> so the files themselves are also chains... 
22:46:39 <docl> yeah
22:46:56 <tangentstorm> and if you delete a file what do you do about filling in the gaps?
22:47:33 <docl> does the link belong at the end of the file? or is there a file description array somewhere that tells us where all the bits of memory are?
22:48:09 <tangentstorm> i would think you'd want to make it a doubly linked list
22:48:31 <tangentstorm> for small files it probably doesn't matter
22:48:52 <tangentstorm> but if you want to append, you need one end, and if you want to cat you need the other end
22:49:00 <tangentstorm> s/cat/read
22:49:59 <docl> well you could apply @ until you hit 0 like when we walk the dictionary
22:50:06 <tangentstorm> but just starting at the end just like a dictionary is probably fine for personal use
22:50:32 <tangentstorm> yeah... doubly linked is overkill
22:51:02 <tangentstorm> seek() is interesting though
23:07:50 --- quit: kumul (Quit: WeeChat 0.3.9)
23:59:59 --- log: ended retro/12.10.06