00:00:00 --- log: started forth/05.08.05 00:23:01 --- join: Amanita_Virosa (~jenni@CPE0000e812679b-CM000a7362da55.cpe.net.cable.rogers.com) joined #forth 00:24:53 --- quit: ramkrsna_ ("Leaving") 00:26:18 --- join: Topaz (~top@spc1-horn1-6-0-cust128.cosh.broadband.ntl.com) joined #forth 00:40:15 --- join: aum (~aum@port-219-88-128-10.orcon.net.nz) joined #forth 00:55:27 --- quit: true-grue () 01:03:58 --- quit: Topaz (Remote closed the connection) 01:36:53 --- join: true-grue (~true-grue@office.medlux.ru) joined #forth 01:39:24 --- quit: JasonWoof ("off to bed") 01:55:18 --- quit: moreCowbell (Read error: 113 (No route to host)) 02:14:16 --- quit: Amanita_Virosa ("Click! :P") 02:22:23 --- join: Topaz (~top@spc1-horn1-6-0-cust128.cosh.broadband.ntl.com) joined #forth 03:19:17 --- quit: Topaz ("Leaving") 04:14:46 --- quit: true-grue () 04:40:27 --- quit: swalters (Read error: 104 (Connection reset by peer)) 04:45:49 --- join: swalters (~swalters@2416457hfc118.tampabay.res.rr.com) joined #forth 05:02:23 --- quit: aum () 05:21:10 --- join: Topaz (~top@spc1-horn1-6-0-cust128.cosh.broadband.ntl.com) joined #forth 06:25:04 --- join: JasonWoof (~jason@Herkamire.student.supporter.pdpc) joined #forth 06:25:04 --- mode: ChanServ set +o JasonWoof 06:33:02 --- join: madgarden (~madgarden@London-HSE-ppp3546403.sympatico.ca) joined #forth 06:34:42 --- join: PoppaVic (~pete@0-1pool74-106.nas24.chicago4.il.us.da.qwest.net) joined #forth 06:36:14 Hi-ho 07:18:10 --- join: sproingie (foobar@64-121-15-14.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 07:29:37 --- quit: cmeme ("Client terminated by server") 07:30:21 --- join: cmeme (~cmeme@216.184.11.2) joined #forth 07:43:47 --- quit: PoppaVic ("Pulls the pin...") 07:48:50 --- join: virl (~hmpf@chello062178085149.1.12.vie.surfer.at) joined #forth 08:08:22 --- join: PoppaVic (~pete@0-1pool46-45.nas30.chicago4.il.us.da.qwest.net) joined #forth 08:11:13 --- quit: sproingie (Remote closed the connection) 08:11:22 --- join: sproingie (foobar@64-121-15-14.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 09:17:52 --- join: moreCowbell (~moreCowbe@ca-lapuente-cuda2-c1c-186.arcdca.adelphia.net) joined #forth 10:39:56 slava, does Factor notice when a type never changes and do some static typing? if not is it possible to do static typing in factor? 10:41:26 mostly i'm thinking about how tuples seem to be the replacement for structs. 10:41:44 bullshit 10:42:48 what? 10:43:24 OrngeTide, yes, there is some type inference 10:43:57 slava, how does that work? 10:44:23 very simple iterative dataflow analysis 10:44:40 its only in the cvs version 10:44:48 ah. neat:) 10:45:07 how's the speed of factor compared to C? 10:45:15 the type information is used for two things at this stage: turning type checks that are always/never satisfied into literal true/false, and inlining a method of a generic word if the same method will be called every time 10:45:25 * OrngeTide recently tried to implement some stuff in ruby, and it was embarassingly slow. 10:45:30 the speed is somewhere between STC forths like retro, and C 10:45:41 that's pretty good. 10:46:26 some things are rather slow, like I/O 10:46:40 the reason? 10:46:56 i haven't put time into optimizing it yet 10:47:01 fair enough:) 10:47:11 also, I/O words rely on continuations, which do not compile, so they run in the (rather slow) interpreter 10:47:23 this will change soon. in fact the interpreter is going away 10:47:26 ah. that's why:) 10:47:37 oh. you think you'll be able to eliminate the interpreter entirely? 10:47:58 s/think/know/ :) its a matter of redesigning a few things. i can explain specifics if you're interested 10:48:52 i'm interested. but i'm busy with work right now. 10:48:55 right now i use the same data type for lists and code blocks 10:49:12 the compiler does dataflow analysis to see what lists end up in the evaluator, and compiles those inline 10:49:17 ah. sort of how lisp works 10:49:27 however, it doesn't catch all such lists/code blocks... eg, where continuations are used, or catch/throw 10:49:35 i'm going to change code blocks to be a distinct type 10:50:04 right because those would be evaluated later and end up looking like normal lists? 10:50:45 will having distinct code blocks change the syntax? like #[ code ] .. or something? 10:50:53 basically right now i have the interpreter which runs lists/code blocks, and an optimizing compiler that compiles *entire words* with dataflow analysis 10:51:06 the optimizing compiler will stay, but the interpreter will be replaced with a simple STC system 10:51:12 indeed, the two will share code 10:51:16 the optimizing compiler is just a stage on top 10:54:11 what is STC? 10:54:23 subroutine threading 10:54:33 gotcha 11:01:23 slava, comparisons.pdf: When writing lists, you have to make sure you but spaces around both 11:01:29 brackets. 11:01:56 (typo, I assume) 11:17:52 --- join: samc (~sam@203-114-131-28.inspire.net.nz) joined #forth 11:20:37 slava, also there is a . starting at the beginning of a line that doesn't make sense (in the same file). . But Factor has many semanically... 11:20:53 i dunno if you are interested in free proofreading. :) 11:21:01 i am, but i'm not the author of that document 11:21:05 talk to LittleDan in #concatenative 11:22:14 okay. 11:36:25 --- nick: Raystm2_ -> nanstm 11:39:27 --- quit: PoppaVic ("Pulls the pin...") 11:46:26 --- join: arke_ (~chris@p54A7E1E9.dip.t-dialin.net) joined #forth 12:06:29 --- quit: arke (Read error: 110 (Connection timed out)) 12:48:12 how often do you use in your programs numbers which are higher than 255? 12:48:41 i write number theoretic code which deals with numbers whose sizes are measured in kilobytes 12:50:19 like calculating pi? 12:50:26 err, no 12:50:45 integer stuff 12:52:15 aha.. 12:55:26 the point is, I have some problems to find the most portable cell size. at the point unsigned char looks good in that case. 12:55:54 ugh, you want a pointer to fit in your cell 12:56:39 yeah, but I have a vm so I'm flexible in that case. 12:58:10 I mean, I'm designing the memory model, so I can decide which size I use for a pointer. 12:58:24 you'll have unsigned char pointers? 12:58:28 only 256 memory locations? 12:59:16 the core yes, could be. 12:59:20 oh, it was the factor library 12:59:27 oops wrong window 13:00:09 virl, that's far too small 13:00:20 yes indeed 13:01:01 you would need an ugly segmented system 13:01:24 hmm so ugly isn't that. 13:01:36 ? 13:01:44 for me.. 13:03:37 it wouldn't be ugly unless you needed a vector 256 bytes or longer 13:03:47 which comes up all the time 13:03:56 which for most things 13:03:57 you know I'm experimenting at the time with ideas about a portable forth system which should be a java killer... 13:03:59 yes 13:04:20 a 'java killer' would have to be a smalltalk or lisp derivative 13:04:40 ok, a java vm killer... 13:04:41 something object oriented... 13:05:22 but goodness doesn't determine what lives and dies 13:05:28 I'm only designing at the moment the underlying vm, that doesn't mean, that ontop of that is riding a bloated oop shit system. 13:05:47 the java vm is closely tied with the java language, the vm is oop (opcodes for method dispatch, etc) 13:06:34 anyone looked at parrot? 13:06:39 I meant more a .net approach, one vm different languages. 13:06:44 yes, me. 13:06:45 .net is identical to java 13:06:52 CLR (.net's VM) is closely tied to C# 13:07:12 ok, then .net is a big shit, more crappy than java. 13:07:25 virl, nevermind I found an answer 13:08:13 virl, have you ever coded in C# or java? 13:08:17 every vm which has more than 110 opcodes is a holly crap. 13:09:50 why, everybody asks me if I coded in java? hell, yes and it's developers should die a long slow death. 13:10:09 how long did you spend coding it? 13:10:23 i worked in java for 9 years before i gave up on it and decided it was trash 13:11:11 slava, you in nz? 13:11:17 no, canada, why? 13:11:42 slava, respect you had a long breath. 13:11:49 oh just a factor link was an .nz 13:11:56 * samc is in nz 13:12:03 samc, oh, that's doublec's box. he lives in auckland. 13:12:10 samc, i used to live in wellington until 2002. 13:12:14 slava, I coded in it one year. 13:12:30 virl, i like OOP very much, though. 13:13:01 ah! life on the channel :) 13:13:09 and I say oop doesn't need a language which has the label of oop programming. 13:14:10 seems there are disproportionately many at-some-time nzers interested in concatenative languages 13:14:23 virl, i think it does 13:14:26 does anyone know of a lisp (with source available) implemented with a threaded interpreter. The only one I can find is a commercial product 13:14:30 just like functional programming is best done in a functional langauges, etc 13:14:37 moreCowbell, clisp.cons.org 13:14:45 it uses bytecode ("token threading") 13:14:52 ah! sweet 13:14:56 thanks 13:15:06 its kind of slow 13:15:38 slava, have you used mops? 13:15:43 slava I think not 13:15:46 no, i've heard of it though 13:19:41 and most of the languages which use OOP, use it too much and everytime, I think that's the worst approach in the history of programming language. 13:19:55 i like 'everything is an object' 13:22:11 'wow', everything is an object, that's true, but that isn't a feature of a programming language, only of your ability to imagine, that everything is an object. 13:22:13 I didn't until I used io 13:22:27 virl, it is a feature of a programming language. 13:23:15 ok, when you mean... 13:23:26 I don't think so... 13:23:41 in factor, i can ask every object to print itself as code that reconstructs that object. 13:23:50 i can compare any two objects for equality (not just pointer equality!) 13:24:03 i can store objects in vectors, hashes... 13:25:34 if i have a pointer to some object, i can ask it, at runtime, what its type, shape and slots are 13:30:27 ok, nice features. but for what are you smashing that complexity into your language? 13:31:22 for writing applications 13:31:44 aha.. 13:34:46 for int,floats,string and another fundemental datatypes I see simple solutions for simple problems like comparing a string '123' with a real int '123', but how is it with other objects? 13:35:02 the string "123" does not equal the integer 123 in factor... 13:35:10 for lists, arrays and hashes, you compare their contents 13:35:12 for tuples, you compare slots 13:35:19 it looks like that you did some of the better implementations of oop out there. 13:35:29 its no different from what you'd find in comon lisp or smalltalk 13:38:49 one point about oop is, that it's most of the time wrong used and results in too complex libraries and apis. 13:39:00 not really 13:39:12 java does it wrong and most C++ coders do it wrong. 13:39:23 neither java nor C++ implement OOP very well 13:39:47 in fact, they are not OOP enough 13:40:21 yes, they use it wrong ;-) 13:41:51 on the other side, languages which implement it well doesn't have a good runtime behavior. iirc, I saw a comparison between python and Java, Java was faster than python. 13:42:17 python is really badly implemented 13:42:32 take a look at a good common lisp implementation, sbcl is very fast for example 13:42:33 or factor 13:44:25 ok, not a good argument. 13:45:24 somehow this discussion goes into a wrong direction. 13:45:40 because you don't have a provable point... 13:47:03 the proveable point is that look at most programs and see how they use it wrong, even when it's a C++ implementation of oop. 13:47:20 most non-OOP procedural programs are terribly ugly... 13:48:05 That's a bit sweeping. 13:48:25 s/most/many/ 13:48:29 and not everything should be an object, objects make a sense there where you want to build a method hierarchy. 13:48:31 One might as well assert that most OOP programs make inappropriate use of inheritance. 13:49:33 another thing is, I'm not against oop and I think that you think that I'm are. 13:49:59 yep, that's true. too much hierarchy 13:51:10 or when you depend on another classes too much, Java for example with it's bufferedstream & tokenizer classes. 13:53:10 is the making of starflight anywhere on the web? the sonic site seems to be down 13:59:44 and I only want to write a portable vm for non heavy oop based languages. 14:00:11 the mix makes the sense ;-) 14:06:22 slava, everything ok? 14:08:30 Many programs are terribly ugly. Many programmers are untalented. 14:09:11 There's a connection there. But to suggest OOP somehow adds beauty to programs from an untalented programmer -- that's a reach. 14:10:21 a reach? 14:10:30 Wrong, that is. :) 14:10:47 full ack, to that. 14:12:40 and often oop adds more text to write an extreme example of java: System.out.println("blah"); non oop: print("blah"); too much text, for a lazy man like me. 14:18:31 I believe paul graham has some good essays on the op of the problems of oops for oops sake 14:22:26 the best thing to realize that, is using oop AND structured procedural programming. 14:26:15 --- join: bordeh (~bode@comonline.dig.polimi.it) joined #forth 14:26:19 hello 14:26:23 is chuck moore home? 14:27:43 --- nick: bordeh -> bode_ 14:28:27 --- nick: bode_ -> bordeh 14:35:15 hi 14:35:20 no, he doesn't visit here 14:35:22 he did once 14:35:27 but thats all :D 14:35:29 --- nick: arke_ -> arke 14:37:42 really he visited once? what did he say? =) 14:37:52 its online 14:37:59 look for chuck moore #forth on google 14:39:18 slava, how much opcodes does your vm have? 14:43:01 wah, the chatlog doesn't exist anymore. deadlink.. who is the #forth website admin? 14:43:20 dont know.. 14:44:05 Moore has injected himself momentarily into a few forth discussion venues. I think he does it so he can tell others later how misunderstood Forth is. 14:45:14 Oh? 14:45:23 Well, I mean, where is he discussing? 14:45:43 Currently nowhere I know of. He's been in comp.lang.forth from time to time. Unfortunately Jeff Fox seems to speak for him most of the time. 14:46:02 Oh yeah. 14:46:10 Occasionally on the colorforth mailing list 14:47:32 --- quit: samc () 15:00:09 --- quit: nanstm (Read error: 104 (Connection reset by peer)) 15:49:13 --- quit: Topaz (Read error: 104 (Connection reset by peer)) 15:49:17 --- join: Topaz (~top@spc1-horn1-6-0-cust128.cosh.broadband.ntl.com) joined #forth 15:57:58 --- join: Raystm2 (~vircuser@adsl-68-93-40-183.dsl.rcsntx.swbell.net) joined #forth 16:33:46 --- quit: bordeh () 16:44:31 --- quit: Topaz (Remote closed the connection) 16:46:15 --- join: Al2O3 (~Internati@24-55-116-96.clspco.adelphia.net) joined #forth 16:48:59 --- quit: Al2O3 (Read error: 104 (Connection reset by peer)) 16:59:30 --- join: TheBlueWizard (TheBlueWiz@ts001d0725.wdc-dc.xod.concentric.net) joined #forth 17:08:53 --- part: moreCowbell left #forth 18:45:22 --- join: snoopy_16 (snoopy_161@dsl-084-058-131-069.arcor-ip.net) joined #forth 18:46:10 --- quit: sproingie (Read error: 110 (Connection timed out)) 18:53:43 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 18:53:57 --- nick: snoopy_16 -> Snoopy42 19:07:38 --- join: aum (~aum@port-60-234-97-196.orcon.net.nz) joined #forth 19:26:40 --- part: TheBlueWizard left #forth 19:57:43 --- quit: aum () 22:25:06 --- join: Raystm2_ (~vircuser@adsl-68-95-254-73.dsl.rcsntx.swbell.net) joined #forth 22:33:38 --- quit: Raystm2 (Read error: 60 (Operation timed out)) 22:35:00 virl, factor does not have a vm or opcodes, it compiles to native code 22:50:07 --- join: sproingie (foobar@64-121-15-14.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 23:06:39 --- join: moreCowbell (~moreCowbe@ca-lapuente-cuda2-c1c-186.arcdca.adelphia.net) joined #forth 23:44:57 --- quit: sproingie (Remote closed the connection) 23:59:59 --- log: ended forth/05.08.05