00:00:00 --- log: started forth/05.12.30
00:07:22 --- quit: amca_ (Read error: 110 (Connection timed out))
00:39:44 --- join: Cheery (i=Henri@a81-197-18-99.elisa-laajakaista.fi) joined #forth
00:50:46 --- nick: Pragger|SIGHUP -> Indesanguinable
00:52:01 --- nick: Indesanguinable -> Pragmatic
01:09:40 <amca_at_cins> what does Indesanguinable mean?
01:17:40 <virl> hi.
01:18:17 <virl> what's shaking?
01:20:31 <amca_at_cins> The tree of happiness?
01:21:07 <virl> heh?
01:21:36 <virl> I meant: whats going on?
01:24:06 <amca_at_cins> I know
01:24:09 <amca_at_cins> Sorry
01:24:17 <amca_at_cins> In a very "loose" mood right now
01:24:32 <amca_at_cins> Currently Im just reading up about stuff
01:24:40 <amca_at_cins> coding stuff
01:24:53 <amca_at_cins> Or as my gf and I refer to it: coding pr0n
01:31:18 <amca_at_cins> What are you doing?
01:32:18 <virl> coding at my project
01:33:41 <amca_at_cins> How is it going?
01:35:09 <virl> sometimes good and sometimes not ;-)
01:35:15 --- quit: crc (Read error: 110 (Connection timed out))
01:37:05 <amca_at_cins> hehe
01:37:55 <amca_at_cins> Sorry, try as I might to wrack my brains, I cant recall your project.
01:38:23 <virl> it's called 'xell' and can be found on 'xell.forthworks.com'
01:39:28 * amca_at_cins looks
01:40:50 <amca_at_cins> What has been the good?
01:41:32 <virl> what do you mean? I don't understand
01:42:07 <amca_at_cins> The good as in "sometimes good and sometimes not"
01:43:01 <virl> good = I'm not frustrated; I don't think it's useless and write some piece of code
01:44:02 <amca_at_cins> and the not?
01:44:30 <virl> the opposite of the good
01:45:49 <amca_at_cins> ah
01:46:01 <amca_at_cins> Does any predominate?
01:46:42 <virl> and I don't know how to explain it to other people or I don't know in what direction exactly I'm moving with it, because it has so much interesting details, which all need to get explained and expressed in it.
01:48:20 <virl> the next which could have a relation to it, could be java, at the start of the project I thought only I'll do a java killer, but at the moment I think I do something which goes in a different direction than java.
01:49:09 <amca_at_cins> hmmm
01:49:34 <amca_at_cins> Which is the different direction?
01:53:01 <virl> java direction: show people how to slow down code; with gc and a lot of security buzzwords; declare big standards which make it hard to implement it by other people; follow the philosophy 'everything in this standard must be presented'; don't allow a tools-framework; build everything on OOP; (don't have multiple syntaxes for the language); need class files to live
01:55:01 <amca_at_cins> And the different direction? Is it simply the opposite?
01:59:03 --- join: PoppaVic (n=pete@0-1pool64-209.nas22.chicago4.il.us.da.qwest.net) joined #forth
02:00:04 <virl> xell direction: doesn't need an extra format for bytecode files, they are all raw; doesn't need gc, explicit, the implementor of the vm can add one when he want; use of a problem domain related bytecode api; follows the philosphy 'everything needs to be simple as possible to achieve a relative stable vm'; philosophy2 'errors are only some little kids which should be ignored, but the system should be shielded against the damage, this little kids did'
02:00:29 <virl> something in that direction, the problem is it's not easy to explain it.
02:03:49 <amca_at_cins> I see
02:03:54 <amca_at_cins> I think I get the idea
02:04:32 <PoppaVic> Ideas are good
02:05:26 <amca_at_cins> PoppaVic: Some ideas are betterthan others ;)
02:05:38 <PoppaVic> This is true
02:06:06 <virl> amca_at_cins, oh really?
02:06:53 <amca_at_cins> virl: Yep. But Im not sure how to work out whether one idea is better than another 
02:07:29 <virl> no, I meant that got the idea
02:07:31 <PoppaVic> Tests (trial & error), readability, portability, speed, size - pick a few ;-)
02:13:31 <virl> amca_at_cins, do you find it interesting? or not?
02:15:23 <amca_at_cins> Yes, in that it is a VM design, and I am interested in VMs. Im not sure though how useful it is, especially in how it is different to everythiong else out there. For example, what can it provide that other languages/VMs cant?
02:18:41 <virl> a direct bytecode api for guis, io, etc. I haven't seen that yet in other vms, so I think that's unique.
02:18:58 <virl> (probably not)
02:19:40 <virl> or it has a cyclic data stack, I don't know any vm which has a cyclic data stack.
02:19:50 <amca_at_cins> why a cyclic data stack?
02:20:43 <virl> because with that it's possible to reduce boundary checking.
02:21:08 <virl> is it at the end? is it at the end? shit it's at the end->cry!!
02:22:03 <amca_at_cins> lol. on the other hand, the stack keeps quiet if you write over your other parameters. Myself I would prefer the stack to complain noisily
02:23:11 <virl> with that I say: 'ok programmer/compiler, that is the size, you can keep track or use not so much items, but when you fucking moron do a flip-over then be sure that you overwrite your own data'
02:24:14 <amca_at_cins> Also wiith a linear stack, if you get a under or overflow, the generated error could trigger a stack save/restore to memory
02:25:27 <virl> but what happens when it complains noisily? it needs a back stream(xell vms, are independent and designed to work at their own) to the user, only for error checking? I think that should catch the ide/interface to the user, not the vm.
02:27:12 <PoppaVic> Hot shit, I fixed that silly-bug
02:30:38 <virl> amca_at_cins, when you remove all that end checking or triggering things, which one of the two stacks causes a segfault?
02:31:49 * amca_at_cins tries to think
02:32:06 <amca_at_cins> neither?
02:33:10 <amca_at_cins> I would suggest that the stack keeps over/underflow checking
02:33:13 <virl> linear stack: tos = tos + 1 cyclic stack: tos = tos +1; tos = tos & memorygroup
02:35:03 <virl> so the linear stack would cause a segfault
02:35:39 <virl> over or underflow checking are features which can be build into both stacks, also triggering.
02:36:18 <amca_at_cins> that's what I meant
02:38:11 <virl> and I meant that, they are only features, but it should be also possible a xell vm without it.
02:38:45 <amca_at_cins> true
02:40:14 <virl> when you throw away javas last 30 bytecodes or something like that, it will probably not function, xell would.
02:41:15 <amca_at_cins> in the java class file?
02:41:20 <virl> javas bytecode isn't flexible it's only static, xells bytecode is flexible. 
02:41:57 <virl> no, the last of javas 140 bytecodes, whatever a jvm has.
02:42:12 <amca_at_cins> can you "reprogram" parts of the byte code to execute routines of other bytecodes?
02:44:51 <virl> xell bytecode consists of a small core and a big user-area, the core which isn't changeable consists of only 30 - 32(I'm designing it yet) and the rest of it is fully reprogrammable.
02:45:32 <virl> I like the concept of it.
02:46:28 <amca_at_cins> what do you mean by "bytecode"? According to my understanding, "bytecode" refers to a VM's instruction word.
02:46:36 <virl> with that it's possible to build a totally problem specific instruction set.
02:47:36 <amca_at_cins> Sounds like a Forth variation
02:48:32 <virl> it is a forth variation, that is why on my project page stands big in glory letters 'Forthish'
02:50:24 <amca_at_cins> Ah. I just looked in the "About" page for details
02:51:09 <virl> ok.
03:05:45 <virl> other things which you find interesting about it?
03:06:38 <amca_at_cins> Im looking forward to see documentation on the actual bytecodes to be implemented
03:09:35 <virl> I have some here around but the documentation is in german.
03:09:55 <amca_at_cins> hehe
03:10:01 <amca_at_cins> I only read English sorry
03:10:36 <virl> yes, that was what I thought ;-)
03:10:52 * amca_at_cins nods :)
03:12:59 <virl> I think I work on that, after I did my first real implementation of it.
03:13:14 * amca_at_cins nods
03:13:20 <amca_at_cins> I do stuff the other way first
03:13:31 <virl> currently in 'C', will be probably slow.
03:14:07 <virl> with that I test it before I write shit and publish it.
03:15:25 <amca_at_cins> You code it in German or English?
03:20:57 --- quit: Jim7J1AJH (Read error: 110 (Connection timed out))
03:22:13 <virl> I code it in english, but I did the documentation for me in german
03:22:48 <virl> which are a skratch-paper 
03:23:49 <amca_at_cins> Ah. Fair enough
03:40:57 --- quit: amca_at_cins ("braindead")
03:54:55 <virl> hmm... when I understand valgrinds output correctly, then factor leaks a little bit.
04:08:03 --- join: Jim7J1AJH (n=jim@221x115x224x2.ap221.ftth.ucom.ne.jp) joined #forth
04:39:35 --- quit: tathi ("leaving")
04:48:08 --- join: crc (n=crc@pool-70-110-218-38.phil.east.verizon.net) joined #forth
04:57:32 --- quit: PoppaVic ("Pulls the pin...")
06:59:40 --- quit: swalters_ (Read error: 110 (Connection timed out))
08:12:56 --- join: swalters_ (n=swalters@6532183hfc82.tampabay.res.rr.com) joined #forth
08:14:24 <virl> hiho swalters_ 
08:19:29 --- join: ios14 (i=S@dynamic-vpdn-250-113.telecom.by) joined #forth
08:34:02 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth
08:34:02 --- mode: ChanServ set +o JasonWoof
08:42:56 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
08:43:38 --- quit: snowrichard (Client Quit)
08:46:47 --- part: ios14 left #forth
11:36:53 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-161-119.pools.arcor-ip.net) joined #forth
11:45:14 --- quit: Snoopy42 (Read error: 145 (Connection timed out))
11:45:16 --- nick: snoopy_1711 -> Snoopy42
11:46:29 <slava> virl: that's strange
11:46:39 <slava> virl: if valgrind shows leaks, then it is because of C libraries that factor calls
11:47:00 <slava> object memory and GC is managed in one mmapped arena that valgrind won't care about
11:57:55 <virl> why shouldn't it care about?
12:15:51 --- quit: swalters_ (Read error: 104 (Connection reset by peer))
12:33:08 <slava> virl: because valgrind only checks malloc/free usage
12:33:13 <slava> not custom memory managers
12:34:40 --- join: swalters_ (n=swalters@6532183hfc82.tampabay.res.rr.com) joined #forth
13:14:40 <virl> you mean your mmaped memory area?
13:15:50 <slava> yes, as far as valgrind is concerned, i'm just reading and writing random bytes there
13:16:10 <slava> so if valgrind reports leaks, its a problem in how i use opengl, freetype or sdl
13:16:21 <slava> because some of the calls in those libraries allocate memory implicitly
13:22:55 <virl> at the moment I use malloc/free
13:25:22 <virl> for my portabler version of xell, then probably I'll play with mmap.
13:25:33 <virl> I never really did that
13:26:56 <slava> i have a garbage collector so malloc/free is not really an option
13:30:04 <virl> and I think garbage collectors aren't a solution.
13:30:23 <slava> why not? have you implemented one or used a language with GC?
13:31:38 <virl> I used several languages with a gc, nice but only toys which lead for me to lesser control and speed loss.
13:32:59 <slava> what control do you lose?
13:33:20 <virl> and some were really damn slow, java was/is so slow, urgh.
13:33:44 <slava> java is slow because of a badly designed library
13:33:55 <slava> you can observe the same problem in, eg, mozilla
13:33:56 <slava> its too bloated
13:35:33 <virl> I can't say when it collects data, so I lose the control over it, which makes it unuseable for me.
13:37:52 <slava> why do you want to control when objects are deallocated?
13:41:42 <virl> ehm, games, timing is everything.
13:42:01 <slava> so you're concerned about GC pauses?
13:43:12 <virl> yes, and that I can't really control what the GC deletes, I can only work somehow around the GC algorithm.
13:43:55 <slava> well, you can control what the GC deletes -- it deletes objects that you cannot reach
13:44:14 <slava> what is the maximum pause time your applications require?
13:48:00 <virl> the minimum possible.
13:48:33 <slava> common incremental GC techniques usually have pause times between 1-10ms
13:49:12 <virl> java should use a good gc technique, nor?
13:49:14 <slava> factor doesn't have incremental GC yet. the average pause time is < 1ms but unfortunately the worst case is not bounded -- with an average-size heap it could take 100ms to do a GC for example
13:49:44 <slava> i'm going to implement incremental GC at some stage next year
13:50:27 <virl> does java use incremental GC?
13:50:32 <slava> yes
13:50:41 <virl> so then it's too slow
13:50:43 <slava> java's GC is good; their library is terrible
13:50:52 <slava> any GC is slow if you have 2 million fucking objects in your heap
13:53:32 <virl> ok.. I never counted it.
14:00:43 --- quit: Cheery ("Leaving")
14:11:26 <virl> so everybody should use GC because it's so fast and completly good; I prefer it todo it on my own for specific task, for everything else there are toy languages 
14:16:44 <slava> being a toy language or not is unrelated to having GC
14:18:04 <slava> GC makes code easier to debug and creates less work for the programmer
14:21:35 <virl> I think it's a direction of doing things where no really good alternative is around.
14:37:53 <virl> lets say it simple, I never saw one language or framework which handled it well and then I think it leads to complexity and error vulnerability.
14:38:48 <slava> a gc is only a few hundred lines of code
14:39:47 <virl> yes I know
14:45:38 --- join: asymptote (n=weldon@220.muma.nsvl.chcgil24.dsl.att.net) joined #forth
14:49:56 <slava> virl: programmers are prone to prejudice. you should evaluate everything based on technical arguments instead of being a zealot. zealotry leads to bad technology (look at java)
14:52:56 <imaginator> hi slava
14:53:38 <slava> hi
14:53:44 <imaginator> re: your GC.  I was curious about all of the techniques, so I bought the Garbage Collection book
14:53:57 <imaginator> the copying technique seems more useful than I first gave it credit
14:58:02 --- log: started forth/05.12.30
14:58:02 --- join: clog_ (n=nef@bespin.org) joined #forth
14:58:02 --- topic: 'Welcome to #forth. We discuss the Forth programming language, simplicity, and a variety of technical subjects. The rules are simple: don't spam, don't troll, and please speak English.'
14:58:02 --- topic: set by SunDragon on [Sat Dec 10 07:19:28 2005]
14:58:02 --- names: list (clog_ asymptote swalters_ Snoopy42 @JasonWoof crc Jim7J1AJH madgarden OrngeTide warpzero ianp Ray_work humulus ccfg ramkrsna saon clog Pragmatic skylan Raystm2 Robert imaginator virl slava)
14:58:42 <imaginator> handling all of the conditions where the power could be killed, and preserving enough metadata has been difficult.  I think it would be even more difficult without a copying GC
15:00:12 --- quit: madgarden (Read error: 110 (Connection timed out))
15:00:38 <virl> slava, I'm only pragmatic.
15:01:45 <slava> what kind of programs do you write?
15:02:42 <asymptote> eh
15:02:49 --- quit: asymptote ("Leaving")
15:03:45 <virl> which choice do I have? you only want to approve your argument.
15:06:06 <imaginator> virl: how do you handle persistant objects or objects that may be shared by multiple parts of your program, and released only once?
15:07:52 * imaginator is honestly wondering, because he wonders how Forth programmers program dynamic memory situations
15:08:14 <imaginator> do you use the pad, or allocate from a pool?
15:09:45 <virl> 'dynamic memory situations' can you elaborate that?
15:10:13 <slava> do you use malloc and free or equivalent functionality?
15:12:50 <imaginator> in my forth book allocate, resize, and free are in the memory wordset.  
15:12:52 <virl> in a C program, yes. but in forth programs, the memory is a playfield for the programmer, he only moves the pointer to it some points forward or backward.
15:14:02 --- quit: clog (Connection timed out)
15:14:03 --- nick: clog_ -> clog
15:18:05 <imaginator> virl: what do you mean by "moves the pointer ... some points forward or backward"  ?
15:18:18 <slava> he means ALLOT/HERE
15:18:29 <slava> which is only useful for the simplest memory management tasks
15:18:31 <imaginator> oh the dictionary/data-space ?
15:20:15 <imaginator> I wonder what the more complex Forth systems do.  How does Win32Forth handle memory management?  I would imagine it's even more complex when using threads...
15:20:56 <slava> it uses a memory pool
15:22:42 <virl> ugh, win32forth.
15:23:00 <imaginator> I suppose the double-free() problem common in C isn't a problem in standard Forth, because if you're using a word to manage the reference to the pointer, then any call to that word after it's gone through forget would fail at runtime.  although I don't know if that works with all Forths.
15:23:06 <virl> a good piece of forth which shows how to not design a forth
15:23:25 <imaginator> virl: why?  it does a lot more than other Forths, doesn't it?
15:23:42 <crc> hi everyone
15:23:49 <imaginator> hi crc
15:23:51 <virl> it's complex and makes headaches to me
15:24:46 <slava> there's no problem with a large library if its well designed
15:25:00 <slava> the goal is to reduce code duplication among programs written in your language
15:27:45 <virl> I never ever saw one which doesn't caused headaches to me.
15:28:09 <slava> do you want to program in machine code on a machine running a simple ROM monitor that loads programs from sectors on a floppy?
15:29:39 <virl> eh, yes and no.
15:30:46 --- nick: Raystm2 -> nanstm
15:33:38 --- quit: crc (Nick collision from services.)
15:34:01 --- join: crc (n=crc@pdpc/supporter/active/crc) joined #forth
15:34:01 --- mode: ChanServ set +o crc
15:35:23 --- log: started forth/05.12.30
15:35:23 --- join: clog (n=nef@bespin.org) joined #forth
15:35:23 --- topic: 'Welcome to #forth. We discuss the Forth programming language, simplicity, and a variety of technical subjects. The rules are simple: don't spam, don't troll, and please speak English.'
15:35:23 --- topic: set by SunDragon on [Sat Dec 10 07:19:28 2005]
15:35:23 --- names: list (clog @crc swalters_ Snoopy42 @JasonWoof Jim7J1AJH slava virl imaginator Robert nanstm ianp OrngeTide warpzero Ray_work humulus ccfg ramkrsna saon Pragmatic skylan)
15:36:15 <virl> and GC is something which is only for Object allocation/deallocation, or what? now I'm confused
15:36:29 <slava> an object is just a chunk of bytes in memory
15:37:45 <virl> and why shouldn't used memory like an array?
15:38:01 <slava> one big array?
15:38:13 --- join: sproingie (n=chuck@64-121-2-59.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth
15:38:17 <virl> yes, like one big array
15:38:27 <slava> don't you subdivide it somehow, and organize its contents?
15:38:44 <virl> I personally prefer that 
15:38:56 <slava> well its not possible to just micro-manage each byte
15:38:59 <virl> organize it's contents? in which sense
15:39:13 <slava> do you just hard-code numerical addresses in your code?
15:39:18 <slava> or do you abstract them?
15:41:46 <virl> abstract? like variable a=2 or what? why should I make it difficult to the machine?
15:41:57 <slava> variables is a simple example
15:42:06 <slava> what about if you want an array of 10 elements
15:42:09 <slava> that's another exampl
15:42:48 <virl> where should be the problem?
15:42:56 <slava> there is no problem
15:43:00 <slava> variables, arrays and so on are abstractions
15:43:07 <slava> just like a memory pool, just like GC
15:44:13 <virl> now it seems senseless, especially for xell.
15:52:03 <virl> somehow I like more the idea of one piece of memory that is efficient used than the idea of a piece of memory where guard looks that the garbage gets collected or the memory area gets resized.
15:52:24 <slava> gc can be more efficient than hand-coded memory management
15:52:52 <virl> that is completly theoretical
15:53:15 <slava> allocating an object in factor is faster than malloc()
15:53:33 --- join: crc_ (i=crc@69.46.24.28) joined #forth
15:54:08 --- quit: crc (Nick collision from services.)
15:54:19 --- nick: crc_ -> crc
15:54:26 --- mode: ChanServ set +o crc
15:56:10 <virl> so how much is it faster?
15:57:11 <slava> i can't give an exact figure but incrementing a pointer is faster than searching a free list
16:10:14 <virl> wise use of malloc/free doesn't cause much speed lose
16:11:25 --- join: Topaz (n=top@spc1-horn1-6-0-cust128.cosh.broadband.ntl.com) joined #forth
16:17:00 <imaginator> virl: it's faster overall, but there may be unacceptable pauses
16:17:18 <sproingie> "wise use of malloc/free" is a pain in the ass
16:18:47 <virl> when you think you need GC then use it daily and everytime. but I don't need it all the fucking time.
16:19:42 <imaginator> virl: Java uses a generational collector, so basically the objects that live the longest are moved into a different pool area, and they are collected less often.  most objects are destroyed shortly after they are created, and those can be reused very quickly.
16:19:53 <sproingie> malloc arenas are a pretty good compromise.  let it leak til you're at a point where you're *sure* you won't need the whole pool again
16:19:58 <sproingie> then just free the whole pool
16:20:06 <imaginator> Java I think uses 3 generations for objects
16:21:04 <imaginator> sproingie: how can you be sure that a pointer isn't still pointing to a chunk that you just freed from the arena?  in what cases have you used such a scheme?
16:21:05 <sproingie> cyclone has static gc for pools.  it frees them when it can prove they'll never be used again
16:21:17 <sproingie> statically, that is, basically inserts a free() in the proper place in the code
16:21:27 <imaginator> that's cool
16:21:46 <sproingie> i haven't used 'em myself, but they're a common idiom for short lived processes
16:21:53 <imaginator> I haven't tried Cyclone yet, but I read a research paper.  it's very interesting stuff
16:22:00 <slava> what is cyclone?
16:22:04 <sproingie> let a thread or coroutine eat all it wants from the pool, then when the coro dies, whack the whole pool
16:22:23 <imaginator> slava: it's a programming language like C, but it's designed to prevent memory usage misuse, and security problems.
16:22:34 <slava> ok
16:22:43 <sproingie> slava: variant of C, adds a lot of good stuff.  as well as some heinously ugly ass syntax
16:22:51 <slava> i hate syntax
16:23:01 <sproingie> it compiles to C, but as far as i know its error output doesn't translate back to cyclone
16:23:11 <sproingie> so badly formed cyclone programs produce some really mysterious errors
16:23:49 <sproingie> most uses of cyclone could probably be filled by mlton
16:24:18 <slava> does MLton do region inference?
16:24:35 <sproingie> no, just plain old gc
16:27:01 <sproingie> you get the pattern matching and parametric types and so on.  syntax doesn't look like perl run through tr/a-z//
16:28:06 <virl> whatever GC is a goodie, like a fancy output.
16:29:33 <sproingie> there are some problems that are virtually impossible without it
16:30:10 <sproingie> say you have two downward continuations and take only one
16:30:25 <slava> the simplest one is of course closures
16:30:36 <sproingie> everything in the other continuation becomes unavailable, instantly
16:30:50 <sproingie> no chance to free it, you gotta gc it
16:31:12 <sproingie> yeah, i guess that was a convoluted closures example
16:32:32 <slava> CPU architectures have a lot of baggage because memory-safe languages never took off for systems programming
16:32:40 <slava> eg, MMU's
16:33:21 <sproingie> there were of course the lisp machines
16:33:37 <sproingie> priced themselves right out of the market in the 80's
16:33:47 <imaginator> I know a guy that used to program on a lisp machine professionally
16:34:15 <imaginator> he didn't like it, because it was running mark and sweep far too often
16:34:29 <sproingie> that can always be tuned
16:34:38 <imaginator> perhaps due to a lack of memory on the lisp machines of that era
16:34:57 <slava> sbcl running on a modern machine is several orders of magnitude faster than a lisp machine
16:35:01 <sproingie> i dont think the gc algorithm itself was in hardware.  just support for tagged pointers
16:35:16 <slava> the gc was lisp code
16:35:26 <slava> the cpu had microcode for type checks
17:02:10 --- quit: Topaz ("Leaving")
18:04:54 --- join: amca_at_cins (i=amca@rdlax11-b218.dialup.optusnet.com.au) joined #forth
18:05:26 <amca_at_cins> Hello
18:05:37 <JasonWoof> allo
18:05:46 <amca_at_cins> How you going?
18:06:56 <slava> hi
18:07:19 <JasonWoof> I'm ok
18:07:42 <amca_at_cins> Hi slava
18:07:54 <amca_at_cins> Did you get my IM yesterday?
18:08:07 <amca_at_cins> JasonWoof: What are you up to today?
18:08:20 <JasonWoof> grrr
18:08:29 <JasonWoof> ok, I'm a bit less than ok. getting frustrated with things a lot
18:08:43 <amca_at_cins> Damn :(
18:08:48 <amca_at_cins> What is going wrong?
18:09:09 <JasonWoof> nothing major
18:09:13 <JasonWoof> just the little things
18:09:24 <JasonWoof> I'm just cranky
18:09:26 <amca_at_cins> All adding up?
18:09:54 <amca_at_cins> slava: The IM I sent yesterday was meant to be a joke. I hope I didnt offend.
18:11:40 <amca_at_cins> Does giving my tasks in a day a nice val;ue make me a geek or just pathetic?
18:13:02 <JasonWoof> huh?
18:13:36 <sproingie> a geek if you do all of them at once
18:13:37 <amca_at_cins> JasonWoof: You know about nice?
18:13:46 <sproingie> otherwise pathetic if you did 'em one at a time
18:13:48 <amca_at_cins> sproingie: All the tasks at once?
18:13:53 <sproingie> that's what nice is for
18:14:22 <amca_at_cins> I have a non-multitasking scheduler.... :(
18:14:40 <sproingie> no need to be nice.  you just needed a queue.  no biscuit for you.
18:15:10 <amca_at_cins> It is more of a hep than a queue
18:15:12 <amca_at_cins> heap
18:16:59 <amca_at_cins> sproingie: Do you know much about heaps? All I know is that they are pretty unordered compared to a queue?
18:17:38 <sproingie> a priority queue is typically implemented as a heap
18:18:29 <amca_at_cins> I think in linux it is a linked list
18:19:01 <sproingie> a heap is a tree where the parent node is always larger than any child nodes
18:19:18 <sproingie> or smaller if you're taking about a min-heap
18:20:21 <amca_at_cins> are there 2 branches per node or can there be more?
18:20:39 <sproingie> not sure how the scheduler in linux is implemented these days.  it's actually quite complex
18:21:02 <sproingie> generically, heaps are usually binary.  they don't have to be
18:22:15 * amca_at_cins nods
18:23:17 <sproingie> the only invariant of a heap is that they're ordered from top to bottom
18:24:02 <sproingie> beyond that, there's probably dozens of subtypes of heaps
18:24:50 <amca_at_cins> sproingie: Have you told me before if you have any projects on the go?
18:25:14 <sproingie> my latest project is to try to learn haskell again
18:25:58 <sproingie> i have a few projects at work that would be really elegant in haskell
18:26:04 <amca_at_cins> cool
18:26:46 <sproingie> the other is to find a java environment that doesn't make me puke.   trails looks nice
18:26:48 <JasonWoof> oh right
18:26:50 <JasonWoof> nice
18:27:08 <JasonWoof> hmm... a few minutes after saying I'm cranky, I find myself cutting the top 2" off a book
18:27:19 <amca_at_cins> O_O
18:27:21 <amca_at_cins> Ouch! How?
18:27:27 <JasonWoof> we find stress relievers in the oddest places
18:27:34 <amca_at_cins> sproingie: As in a Java IDE?
18:27:42 <amca_at_cins> What book?
18:27:43 <sproingie> java dev framework
18:27:52 <sproingie> eclipse is more than adequate for an ide
18:27:56 <JasonWoof> I Suppose I shall Survive
18:28:12 <JasonWoof> not a great book. pulled it out of the recycle because I wanted some padding for the bookend I'm making
18:28:21 <sproingie> trails is like Java On Rails.  it's not well packaged tho.  and the java language itself still sucks
18:28:40 <sproingie> maybe i'll write a spring app in Nice or Scala or SISC or something
18:28:54 <amca_at_cins> How is a dev framework different from an IDE>
18:28:55 <amca_at_cins> ?
18:29:12 * amca_at_cins has nevcer heard of the term "dev framework" before
18:30:21 <JasonWoof> a dev framework can just be a bunch of files that work well together
18:30:52 * JasonWoof concranulates himself on his now bookend
18:31:09 <JasonWoof> cut a bit out of an old freezer basket
18:32:28 <amca_at_cins> What would the linux version of a dev env be? bin/textutils/make etc?
18:32:29 <sproingie> an ide is an editor.  dev framework is a collection of libraries
18:32:54 <slava> why would you use spring with sisc?
18:33:00 <sproingie> a development environment is the whole enchilada.  compiler, editor, libraries
18:33:02 <slava> the whole point of spring is to emulate some dynamic typin
18:33:04 <slava> typing*
18:33:19 <amca_at_cins> I see
18:34:20 <sproingie> spring would be a container, interface with other components.  probably overkill tho
18:34:31 <slava> i know what spring is :)
18:35:33 <sproingie> i'd love to see a container that actually really supported multiple jvm languages.  not just ones that compile to POJO classes
18:36:10 <sproingie> i guess it's a matter of kludging adaptors together
18:36:25 <sproingie> i like the java platform.  hate the language.
18:36:34 <amca_at_cins> hmm
18:36:48 <amca_at_cins> Is the .NET framework any better?
18:37:19 <sproingie> probably
18:37:42 <slava> java libraries suck too
18:38:08 --- join: madgarden (n=madgarde@London-HSE-ppp3547200.sympatico.ca) joined #forth
18:38:29 <sproingie> they're convenient.  most perl libs suck, but they suffice
18:38:32 <amca_at_cins> One thing that seems to me to be a problem with JVM is that it is very Java lang specific. Do you know if the .NET VM is any more generic?
18:38:41 <sproingie> the .NET vm is somewhat more generic
18:38:52 <sproingie> for one, well, it supports generics!
18:39:13 <sproingie> java 1.5 uses type erasure for generics, which is not only unsound, it makes slow code
18:41:46 <sproingie> .net is meant for static languages like the jvm, but its reflection is supposed to be a lot faster
18:41:48 * JasonWoof farts in java's general direction
18:42:16 <sproingie> java's reflection interface is grotesque.  to the point where people write custom bytecode-rewriting classloaders to get around it
18:42:24 <slava> neither the jvm nor .net support closures or continuations
18:42:41 <sproingie> i thought .net specifically supported closures
18:42:55 <slava> ok, i guess i'm wrong there
18:43:20 <amca_at_cins> Sorry, what are closures again? I thought they were blocks?
18:43:22 <sproingie> once you have those, continuations arent so hard.  in the end tho, it's still a stack vm
18:43:35 <sproingie> amca_at_cins: they're blocks that remember their variables
18:43:57 <sproingie> well, not blocks in the forth sense :)
18:44:02 <amca_at_cins> Ah!
18:44:03 <amca_at_cins> I see
18:44:09 <amca_at_cins> like static C variables
18:44:28 <sproingie> somewhat
18:44:43 <sproingie> it's oversimplified, but C static vars are simple static closures
18:45:02 <sproingie> C can't nest functions so you can't do as much with them as you can with real static closures
18:45:35 <amca_at_cins> Ah, I see
19:17:12 <slava> gcc can nest functions
19:35:57 <amca_at_cins> Is there a better way than ">r swap r> swap" to implement a rot word in Forth?
19:38:30 <slava> inline assembler
19:38:59 <amca_at_cins> I meant in terms of other Forth words
19:39:16 <amca_at_cins> Like is that the simplist reduction?
19:39:27 <slava> yes
19:40:12 <amca_at_cins> thanks :)
19:45:13 --- quit: amca_at_cins ("housework")
21:06:17 --- quit: sproingie (Remote closed the connection)
22:30:49 --- quit: swalters_ (Read error: 104 (Connection reset by peer))
22:48:32 --- join: swalters_ (n=swalters@6532183hfc82.tampabay.res.rr.com) joined #forth
22:53:48 --- quit: imaginator ("sleep")
23:29:40 --- quit: JasonWoof ("off to bed")
23:59:59 --- log: ended forth/05.12.30