00:00:00 --- log: started retro/12.04.24 04:15:34 --- quit: jyfl987 (Quit: leaving) 08:13:38 --- join: __tthomas__ (~Owner@24.130.7.34) joined #retro 09:34:41 https://code.launchpad.net/~crc-x/+junk/parable-language 09:35:07 I've setup a repo for parable-related developments 09:35:25 there are a few bits of code, and the latest specifications 09:36:13 * crc intends to have the non-I/O related specs for the bytecode and core language structures finished over the next week or so 09:55:59 <__tthomas__> cool 10:00:29 <__tthomas__> crc you use markdown vs. restructured text? 10:07:24 I mostly use restructuredtext 10:08:21 <__tthomas__> Parable will keep per-symbol documentation in Markdown format. This will be rendered into HTML on the fly. 10:08:30 <__tthomas__> I was just curious about this.. 10:09:48 markdown is a bit easier to handle on the fly (more implementations, simpler format overall) 10:10:36 <__tthomas__> so markdown parsing written in retro or on parable, not dependent on perl? 10:11:25 I'm not going to use perl 10:11:49 <__tthomas__> heh, that was my real question I guess, only implementation of markdown I know of is perl and php 10:11:56 the existance of a javascript implementation is helpful 10:12:02 http://www.showdown.im/ 10:12:59 <__tthomas__> that makes sense, cool, and it is a bit simpler than rst 10:13:41 python at https://github.com/trentm/python-markdown2 10:13:49 <__tthomas__> yeah, just saw that.. 10:14:03 I'm planning to do parable implementations in retro, python, and javascript 10:19:08 <__tthomas__> very cool, I discovered javascript library called lawnchair a while back for client persistent storage.. 10:36:42 client side storage is somewhat problematic for long-term things 10:38:07 <__tthomas__> site storage works pretty well as it persists beyond life of browser/session.. though I would still back it up in case need to use a different computer, it isn't as portable as a file.. 11:47:49 --- join: impomatic (~digital_w@108.171.125.91.dyn.plus.net) joined #retro 12:15:51 --- join: Mat2 (5b4085c5@gateway/web/freenode/ip.91.64.133.197) joined #retro 12:15:56 hi @ all 12:20:15 Hi Mat2 :-) 12:20:28 hi impomatic 12:22:37 wht's new ? 12:22:45 sorry, what'S 12:35:38 --- join: Mat2_ (5b4085c5@gateway/web/freenode/ip.91.64.133.197) joined #retro 12:35:47 server crash... 12:36:00 crc: do you plan a C or assembly port of parable ? 12:38:18 --- quit: Mat2 (Ping timeout: 245 seconds) 12:38:53 Mat2_: not initially 12:39:10 I intend to start with retro, python, and javascript 12:43:35 ok, I follow your sources and work bystep on a C based port 12:43:35 <__tthomas__> hey Mat2_ 12:43:41 hey tthomas 12:46:20 <__tthomas__> Mat2 have you seen any forths with local stack for persisting data between calls.. something like lpush, lpop which works similar to putting data on return stack? 12:50:24 no, only functional forth inspired languages 12:50:44 __tthomas__: I had a build of toka with a third stack separate from the address stack and data stack 12:50:58 tht's nice 12:51:07 sorry, that's nice 12:52:53 I think some of Jeff Fox experimental forth variants implementing stack frames, but not sure 12:53:22 <__tthomas__> crc yeah, I have seen lots of forths with 3rd stack.. especially for implementing and working with floating point.. I was meaning a stack kept local to the word, the word would have a stack pointer and a few cells for implementing a small stack.. I am looking at possible implementations for generators and was curious if something like that had been done.. 12:54:42 <__tthomas__> I have been reading up on stack frames for local variables, there is a nice article on forth.com about it.. 12:55:10 --- join: mat2 (5b4085c5@gateway/web/freenode/ip.91.64.133.197) joined #retro 12:55:20 second server crash... 12:55:47 <__tthomas__> heh, multics server? 12:56:09 *lol*, no just an ubuntu box 12:56:29 (multics without the features) 12:57:03 <__tthomas__> I gave up on Ubuntu 12:57:03 --- quit: Mat2_ (Ping timeout: 245 seconds) 12:57:34 what distro do you use ? 12:57:42 <__tthomas__> debian 6, headless 12:58:32 __tthomas__: I know of nothing like that 12:58:44 <__tthomas__> I also have a linux Mint install somewhere 12:59:18 <__tthomas__> crc nor do I, which means it might be worth my time to mess with.. even if it turns out to be a dead end.. :) 13:03:05 hmm, ok my fig forth for the c128 seem to have a third stack for multitasking support 13:03:41 it is used for some kind of message passing 13:13:07 crc: ok, i've converted the javascript source, to C 13:14:55 <__tthomas__> all popular languages are so similar, I am surprised there isn't an intermediate language and translator for all of them.. 13:21:16 guess it's C 13:22:08 probably pascal would be a better approach, but it is common, its bad 13:25:29 <__tthomas__> haxe does a pretty amazing job of it, though it is a bit heavy and has a pretty extensive library.. processing is fairly decent at it too.. 13:28:04 the problem is that javascript has some builtin features like list processing, pattern matching and garbage collection 13:29:06 I'm fast in converting source-code because have some pattern for these task in mind 13:29:12 tasks I mean 13:32:24 <__tthomas__> yeah, I realize that, but all of these languages also have a very similar subset.. 13:32:45 <__tthomas__> a = 2 + 3 13:37:01 thats true for all Algol inspired languages 13:38:04 where C and descendents are BCPL clones with some kind of undefined behaviour ;) 13:38:05 <__tthomas__> while, if, for, function calls, all are so similar.. there are differences so couldn't do it for 100% of code, but I bet a large portion of most languages could be written in a single codebase and translated.. 13:38:25 that's true I think 13:38:51 with exception of functional languages 13:39:19 <__tthomas__> yeah, and concatenative, which is why I said popular.. :) 13:41:45 hmm, functional languages like pure are very popular, i've switching to pure as replacement for C for future work 13:42:41 it's a functional system-programming language at base 13:45:52 <__tthomas__> hmm.. I would consider popular to be java, C/C++, javascript, csharp, ruby, python, perl, php.. mostly basing this on books published and widely available in bookstores.. 13:47:21 <__tthomas__> also basing it on job postings in my area.. 13:48:02 ok, my problem is: I would not implement system applications in any of these languages except C/C++ if I had the choice 13:48:46 so populary seem to be a function of application 13:49:15 <__tthomas__> for personal projects I mostly use python, though professionally do C/C++ and sometimes for fun javascript.. 13:49:25 <__tthomas__> and C# for work on occassion 13:53:10 <__tthomas__> I think popularity is largely based on support.. C/C++ backed by intel, microsoft, java -oracle/sun, javascript - netscape, python - google.. others made it from need, php solved easy deployment problem, perl is was amazing at string processing on *nix's, ruby had rails ... 13:57:02 yes but this is not for any good 13:57:56 a programmer should be able to found solutions independent of implementation detals like programming languages 14:03:59 that's the ideal 14:05:04 <__tthomas__> that would be awesome, but what I use is dictated by my work not personal preference, and schools largely teach c/c++ and java for curriculum so easy to come by.. 14:05:38 <__tthomas__> there are programmers that make an entire career without ever touching another programming language than what they started with.. 14:09:23 to say it with shakespeare: obvously it is madness, it has method 14:09:50 <__tthomas__> I always heard it as, there is method to my madness.. 14:10:31 <__tthomas__> I am kind of surprised that smalltalk didn't just take over, great dev environment, very portable, basically an entire operating system.. 14:10:32 I have translate it from french to german -> english 14:11:17 <__tthomas__> understood 14:11:37 smalltalk was way to slow even for IBM enterprise demands at time of its popularity 14:12:01 <__tthomas__> ah, I have only played with squeak and pharo, they perform well.. 14:12:19 <__tthomas__> though squeak looked like it was designed for children.. 14:12:28 it is indeed 14:12:47 the initiator for this project was Disney 14:12:56 <__tthomas__> ah, cool.. 14:14:26 smalltalk has had an algol inspired sister called mesa, which was used for implementing the os of xerox's alto 14:16:07 that is the reason for choosing Pascal as programming language for the LisaOS at apple, most programmes worked at Xerox before... 14:19:13 <__tthomas__> cool.. 14:24:05 crc: can you give me a hint how to contribute to your repro ? 14:49:01 --- join: prosser (~androirc@178.110.69.129) joined #retro 14:56:53 --- quit: prosser (Ping timeout: 256 seconds) 15:09:18 <__tthomas__> : exp [ [[ -1 , 0 , 0 , 0 , 0 , 0 , ]] ] ; this works, awesome.. 15:34:21 need some sleep, ciao 15:34:27 --- quit: mat2 (Quit: Page closed) 16:17:48 --- join: Kumul (~Kumul@cvx-ppp-66-50-147-89.coqui.net) joined #retro 16:43:52 mat2: fork it, push changes to a new branch, send me a pull request 16:45:06 I think I have some notes in the retro repo under doc/Contributing.rst 17:13:12 <__tthomas__> Local stack experiment a success, usefulness, debateable.. 19:34:55 --- join: jyfl987 (~jyf@unaffiliated/yunfan) joined #retro 20:12:04 --- quit: jyfl987 (Ping timeout: 245 seconds) 20:12:11 --- join: jyfl987 (~jyf@unaffiliated/yunfan) joined #retro 21:00:56 --- quit: Kumul (Quit: gone) 22:46:41 --- nick: jyfl987 -> jyf1987 23:47:14 --- quit: impomatic (Quit: impomatic) 23:59:59 --- log: ended retro/12.04.24