00:00:00 --- log: started forth/07.11.25
00:30:42 --- join: saon_ (n=saon@c-66-177-56-33.hsd1.fl.comcast.net) joined #forth
00:35:53 --- quit: saon (Read error: 110 (Connection timed out))
01:06:05 --- quit: ygrek (Remote closed the connection)
01:06:05 --- quit: Off_Namuh (Remote closed the connection)
01:07:41 --- join: ygrek (i=user@gateway/tor/x-b10e51843f45ca7b) joined #forth
01:18:04 --- join: Off_Namuh (i=GPS@gateway/tor/x-b2512210d150f9cf) joined #forth
01:30:47 --- quit: ygrek (Remote closed the connection)
01:31:37 --- join: ygrek (i=user@gateway/tor/x-8535f212e3bd7023) joined #forth
01:37:32 --- join: doublec (n=doublec@203-211-87-234.ue.woosh.co.nz) joined #forth
03:15:56 --- quit: doublec ()
03:33:45 --- join: Crest (n=crest@p5B10666F.dip.t-dialin.net) joined #forth
04:30:25 --- quit: Crest (Read error: 113 (No route to host))
05:03:18 --- quit: Off_Namuh (Remote closed the connection)
05:04:59 --- join: edrx (i=edrx@189.25.141.102) joined #forth
05:47:59 --- quit: saon_ ("leaving")
05:58:31 --- join: nighty^ (n=nighty@sushi.rural-networks.com) joined #forth
06:09:02 --- join: ktne (n=ktne@unaffiliated/ktne) joined #forth
06:09:17 <ktne> hello
06:09:34 --- part: ktne left #forth
06:41:20 --- join: nighty-- (n=nighty-@66-163-28-100.ip.tor.radiant.net) joined #forth
06:45:40 --- quit: nighty- (Read error: 110 (Connection timed out))
08:09:19 --- quit: ecraven ("bbl")
08:11:02 --- quit: timlarson (Read error: 104 (Connection reset by peer))
08:11:14 --- join: timlarson__ (n=timlarso@user-12l37rb.cable.mindspring.com) joined #forth
09:43:32 --- join: Crest (n=crest@p5B1068A3.dip.t-dialin.net) joined #forth
09:44:31 <Quartus____> KragenSitaker, the stack can be managed most easily with very small factoring; keeping the number of working items on the stack to 3 or sometimes 4 at most; keeping items on the stack in the order in which they will be consumed.
09:49:40 --- quit: Crest (Read error: 113 (No route to host))
09:57:33 --- quit: Al2O3_ ("Eggplant & SenseTalk: Driving Success Through Automation")
10:00:23 --- join: Al2O3 (n=Al2O3@229.sub-70-215-170.myvzw.com) joined #forth
10:43:04 --- quit: edrx (Read error: 110 (Connection timed out))
10:49:22 --- quit: ygrek (Remote closed the connection)
10:57:08 --- join: edrx (i=edrx@189.25.131.9) joined #forth
12:54:23 --- join: ygrek (i=user@gateway/tor/x-6bccc44b68a140ba) joined #forth
13:08:04 --- join: doublec (n=doublec@202.180.114.137) joined #forth
13:44:27 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
13:44:27 --- mode: ChanServ set +o tathi
14:26:22 --- quit: ygrek (Remote closed the connection)
14:36:57 --- join: frunobulax (n=mhx@e243118.upc-e.chello.nl) joined #forth
14:38:03 <frunobulax> In a not-yet-finished full-text search engine in ANS Forth (http://www.canonical.org/~kragen/tmp/invertedindex.fs.html) I saw:
14:38:16 <frunobulax> : open-input ( c-addr u -- wfileid ) r/o open-file throw ;
14:38:29 <frunobulax> On a good Forth, this will open a file but not create it.
14:38:50 <frunobulax> Gforth for Linux is somewhat too 'helpful' in this regard.
14:39:05 <frunobulax> This has been subject of a clf discussion for a spreadsheet. 
14:39:35 <frunobulax> Example for the generated code:
14:40:26 <frunobulax> Flags: ANSI
14:40:27 <frunobulax> $00548C40  : skip-non-word                            8BC083ED048F4500
14:40:27 <frunobulax> $00548C48  pop         ebx                            5B
14:40:28 <frunobulax> $00548C49  lea         eax, [eax*1 0 +] dword         8D040500000000
14:40:29 <frunobulax> $00548C50  cmp         ebx, [esp 0 +] dword           3B1C64
14:40:29 <frunobulax> $00548C53  jne         $00548C60 offset NEAR          0F8507000000
14:40:30 <frunobulax> $00548C59  push        ebx                            53
14:40:31 <frunobulax> $00548C5A  jmp         $00548C82 offset NEAR          E923000000
14:40:33 <frunobulax> $00548C5F  pop         ebx                            5B
14:40:35 <frunobulax> $00548C60  movzx       eax, [ebx 0 +] byte            0FB603
14:40:37 <frunobulax> $00548C63  lea         ecx, [ebx 1 +] dword           8D4B01
14:40:39 <frunobulax> $00548C66  cmp         [eax $005484C0 +] byte, 0 b#   80B8C084540000
14:40:41 <frunobulax> $00548C6D  mov         ebx, ecx                       8BD9
14:40:43 <frunobulax> $00548C6F  je          $00548C7F offset NEAR          0F840A000000
14:40:45 <frunobulax> $00548C75  lea         ebx, [ebx -1 +] dword          8D5BFF
14:40:47 <frunobulax> $00548C78  push        ebx                            53
14:40:49 <frunobulax> $00548C79  jmp         $00548C82 offset NEAR          E904000000
14:40:51 <frunobulax> $00548C7E  pop         ebx                            5B
14:40:53 <frunobulax> $00548C7F  jmp         $00548C50 offset SHORT         EBCF
14:40:55 <frunobulax> $00548C81  push        ebx                            53
14:40:57 <frunobulax> $00548C82  ;                                          8B450083C504
14:40:59 <frunobulax> How to test this program, as compared to its C prototype?
14:41:01 <slava> please use a pastebin for this in the future
14:42:21 --- quit: frunobulax ("a quit that really quits")
14:43:30 <Quartus____> Impressive.
14:43:48 <slava> there goes my daily fix of random x86 assembly.
15:05:10 <Quartus____> Oh, but terribly important.
15:20:51 <KragenSitaker> Quartus____: indeed, i have heard of very small factoring, keeping working items to a minimum, and keeping ordering of consumption; but I do not know if my difficulties are due to failures to do these things, or due to something else such as inexperience.
15:20:56 <KragenSitaker> maybe you can tell from my code
15:23:24 <slava> you're mixing abstraction layers, i think.
15:23:30 <Quartus____> I think so, too.
15:23:35 <slava> your memory management and low-level string manipulation is interspersed with the high-level words.
15:31:02 <slava> KragenSitaker: i ported your program to factor
15:31:32 <slava> http://pastebin.ca/797402
15:39:55 <slava> its probably even shorter in perl
16:15:53 * JasonWoof crosses his fingers, and starts up a script to convert his mp3s to ogg vorbis
16:16:49 <JasonWoof> it might not finish until morning, I hope it gets it right
16:17:58 <Quartus____> why do it at all?
16:19:57 <JasonWoof> 2 reasons: 1) to fix the broken ones, so I can put propper meta-tags on them 2) so I can run vorbis-gain on them and get uniform loudness from my music collection
16:20:18 <JasonWoof> oh, and it has a certain coolness factor
16:20:35 <slava> my ipod doesn't play oggs :(
16:20:55 <JasonWoof> yeah, I bought a player that does
16:21:14 <JasonWoof> cool little thing. about the size of a C battery
16:22:02 <Quartus____> You can get uniform loudness from defacto extra loudness level dealie in MP3s, too
16:22:20 <JasonWoof> I looked for a replaygain thing for mp3s and didn't see one
16:22:32 <JasonWoof> didn't look all that hard though
16:22:37 <Quartus____> There is such.  Foobar2000 is a player that'll do it for you.
16:23:50 <JasonWoof> I don't run windoze
16:24:08 <Quartus____> Well, I'm sure something similar exists for Linoox.
16:24:18 <JasonWoof> yeah, most likely
16:24:53 <JasonWoof> that's linicks btw ;)
16:26:02 <JasonWoof> it took me a while to write the script, but I get several benifits, including more familiarity with a couple scripting languages
16:26:22 <JasonWoof> and the file-naming scheme I like
16:29:26 <JasonWoof> I figured I'd have to recode to fix the broken old mp3 files anyway
16:29:38 <Quartus____> I wouldn't think so.
16:30:49 <JasonWoof> how else could you fix it?
16:30:54 <JasonWoof> is there some mp3fixer utility?
16:31:05 <Quartus____> Damaged headers?  There are various utilities to fix those.
16:31:15 <JasonWoof> oh
16:32:16 <JasonWoof> I mp3s still have patent issues right?
16:32:21 <JasonWoof> iirc they expire somewhat soon
16:33:20 <Quartus____> I think so.
16:33:35 <slava> factor has an incomplete mp3 player library
16:33:41 <slava> the author never finished it :/
16:33:42 <Quartus____> Re the expiry.  And whatever issues pertain apply to the codecs; they haven't proved any obstacle thus far in any practical sense.
16:34:08 <JasonWoof> yeah they have
16:34:30 <JasonWoof> some of the big linux distros (possibly all of them) don't ship with mp3 playing capability
16:34:48 <Quartus____> You can add the capability with one update.
16:34:53 <JasonWoof> yep
16:35:03 <JasonWoof> but it presents a barrier.
16:35:10 <JasonWoof> it marginalizes Linux
16:36:07 <Quartus____> Ogg Vorbis' name alone marginalizes whatever it appears on.
16:36:21 <JasonWoof> having a weird name isn't nessesarily bad
16:36:29 <JasonWoof> godaddy.com is a nice example of how it can be good
16:36:47 <Quartus____> Ogg Vorbis is a nice example of the opposite.
16:36:51 <JasonWoof> heh
16:37:03 <JasonWoof> I like open standards
16:37:07 <JasonWoof> I make an effort to use them
16:39:11 <JasonWoof> mp3 support can be easily added to linux. it's a recent development I think... it could easily get worse so that big distros dare not support mp3s at all
16:39:31 <JasonWoof> that's just an example of the kind of irritating crap that happens with proprietary formats
16:39:55 <JasonWoof> I realize that this is only marginally related to my music collection
16:40:54 <JasonWoof> it's just a general policy of mine to try to keep my data in well documented and supported (by software) open file formats
16:41:10 <KragenSitaker> slava: 18:39 <@slava> its probably even shorter in perl
16:41:34 <JasonWoof> I figure this makes it most likely that I'll be able to use them far into the future
16:41:43 <KragenSitaker> i mean
16:41:47 <KragenSitaker> slava: thanks! awesome!
16:43:45 <KragenSitaker> also thanks to you and Quartus____ on the design feedback; I'll see if I can figure out how to make the high-level words a little more high-level
16:44:22 <KragenSitaker> it's true that if i don't have to juggle two stack entries every time i touch a string, the stack will get easier to manage...
16:50:47 <KragenSitaker> slava: your rewrite seems to be missing .docids and add: or add-filename, which make it somewhat difficult to tell what else it's missing
16:51:05 <slava> i presume .docids prints the documents containing a search term
16:51:15 <slava> since the index is stored as a hashtable, you use the 'at' word together with the '.' word.
16:51:30 <slava> as far as i can tell, it is functionally equivalent to your version.
16:52:40 <slava> ah, i need to remove dupicates. so if one file has the same word more than once, it doesn't add several entries to that word's index.
16:52:55 <KragenSitaker> yeah
16:52:58 <slava> i could also fold case to make it case insensitive, and use factor's porter-stemmer library to stem words (so that eat and eating index the same, etc).
16:52:59 <KragenSitaker> very nice!
16:53:23 <KragenSitaker> also you could omit punctuation from the words
16:53:37 <slava> yup. instead of using 'split', i could use parser combinators
16:53:49 <slava> and also parse the file incrementally instead of loading it all at once with 'contents'
16:54:04 <KragenSitaker> oh, contents doesn't produce a lazy sequence of bytes?
16:54:09 <slava> no, it loads the file
16:54:37 <slava> support for utf8-encoded files is just a matter of calling a single word on 'contents' to decode utf8
16:55:12 <slava> for directory trees, we have some words too.
16:55:12 <KragenSitaker> you don't even need to do that --- you already have support for them
16:55:33 <slava> factor strings are unicode
16:55:49 <slava> so if your data is stored as utf8, you'd need to decode it for international case conversion to work
16:56:14 <KragenSitaker> international case conversion doesn't work even then
16:56:21 <slava> what do you mean?
16:56:29 <KragenSitaker> dotless i
16:56:54 <slava> we have a library for unicode-aware and locale sensitive case conversion.
16:57:04 <KragenSitaker> but yeah, it's not surprising that it's a lot easier if you start with a reasonably usable library that already implements word splitting, hash tables, memory allocation, and you don't do buffered file input
16:57:06 <slava> not sorting, yet
16:57:18 <slava> factor does buffering under the hood for you
16:57:25 <slava> so you can read one byte at a time if you want
16:57:30 <KragenSitaker> you said contents reads the whole file, though
16:57:35 <KragenSitaker> so your program isn't doing buffering
16:57:37 <slava> yes. but reading a word at a time isn't much harder
16:57:47 <KragenSitaker> right, makes sense
16:57:51 <slava> " \t\n\r" read-until
16:57:56 <slava> you'd do that in a loop
16:58:05 <slava> essentially (there's the EOF case to handle)
16:58:20 <KragenSitaker> but i also don't want to have N levels of function calls in the inner loop
16:59:20 <slava> how much data are you trying to index?
16:59:25 <KragenSitaker> my hard disk
16:59:27 <KragenSitaker> bbl
16:59:29 <KragenSitaker> going to tango show
17:00:16 <slava> sounds like it would be an I/O bound task in any case
17:13:18 --- quit: Deformative (Read error: 104 (Connection reset by peer))
17:13:42 --- join: Deformative (n=joe@c-68-61-240-49.hsd1.mi.comcast.net) joined #forth
18:03:42 --- join: LOOP-HOG (n=jasondam@c-76-105-172-75.hsd1.or.comcast.net) joined #forth
18:19:52 --- quit: LOOP-HOG ()
18:56:48 --- quit: tathi ("leaving")
19:00:22 --- quit: Quartus____ ()
19:00:39 --- join: Quartus (n=neal@CPE0001023f6e4f-CM001947482b20.cpe.net.cable.rogers.com) joined #forth
19:00:39 --- mode: ChanServ set +o Quartus
19:15:07 --- quit: neceve ("Konversation terminated!")
20:06:23 --- quit: doublec ()
20:59:08 --- join: doublec (n=doublec@203-211-100-219.ue.woosh.co.nz) joined #forth
21:02:59 --- quit: doublec (Client Quit)
21:18:00 --- quit: Al2O3 ("Eggplant & SenseTalk: Driving Success Through Automation")
21:21:33 --- join: Al2O3 (n=Al2O3@176.sub-70-215-243.myvzw.com) joined #forth
21:23:30 <KragenSitaker> slava: even in C I haven't gotten it to be an I/O bound task, even on a laptop
21:24:27 <KragenSitaker> I think the best speed I got on a 500MHz laptop was 5 megabytes per second, and it's easy to get hard disks these days that do 40 
21:25:36 <KragenSitaker> for context, that's about 30 times as fast as Lucene, times or divided by three
21:27:20 <KragenSitaker> one of the things people like about Lucene is that it's so fast
21:28:58 <KragenSitaker> Lucene, of course, is extremely flexible and supports a lot of features my indexer doesn't --- document fields, different input formats, and much etc.
21:30:42 <slava> lucene is written in a higher level language
21:31:46 <KragenSitaker> I wonder what Forth frunobulax was pasting from.  It's not bigForth for sure.
21:32:48 <KragenSitaker> yes, it is.  But the other search engines people compare it with mostly aren't.
21:33:16 <slava> i'm porting a syntax highlighting engine i wrote in java to factor.
21:33:23 <slava> i write it several years ago, the code is fugly
21:33:33 <slava> its more of a rewrite than a port, but it reads the exact same syntax highlighting definition files
21:33:35 <slava> that's the idea anyway
21:33:59 <KragenSitaker> is that because you really like the way your syntax highlighting definition files work?
21:34:13 <slava> not particularly -- its a rather minimalist programmable parser
21:34:22 <slava> but, the imporatnt thing is that there are almost 200 language definitions
21:34:39 <slava> some of them are quite elaborate -- html for instance highlights embdded css, javascript
21:34:47 <KragenSitaker> so you'd be better off with something that parsed Vim syntax highlighting definition files instead?
21:34:47 <slava> there's also php which highlights embedded php plus html
21:34:54 <slava> i don't know how vim syntax files work
21:35:07 <KragenSitaker> i guess i'm not certain that they do the embedded css and javascript
21:35:43 <slava> i have a memoization library
21:35:52 <slava> if i change : to MEMO: it defines a word which caches output values
21:36:09 <slava> i figured out a new use for it today
21:36:12 <slava> MEMO: intern-line-context ( context -- context ) ;
21:36:17 <slava> that's a word which does nothing to the top of the stack
21:36:21 <KragenSitaker> cool
21:36:25 <slava> but because its defined with MEMO:, it has the effect if 'internalizing' objects
21:36:31 <slava> i'm using it to save memory
21:36:48 <KragenSitaker> how does MEMO: do equality comparisons?
21:36:58 <slava> polymorphism
21:36:59 <KragenSitaker> vim 7.0 comes with 481 syntax definition files
21:37:10 <slava> vim syntax requires regexps
21:37:11 <KragenSitaker> how does it figure out how many arguments to look at?
21:37:16 <slava> stack effect comment
21:37:17 <KragenSitaker> yes, it's all about regexps
21:37:25 <KragenSitaker> oh, the stack effect comment isn't a comment?
21:37:54 <slava> no, factor checks them. if it doesn't match your code still loads but you get a message
21:38:16 <KragenSitaker> nice
21:38:32 <KragenSitaker> it does look like vim handles embedded JavaScript the way you'd expect:
21:38:33 <KragenSitaker>   syn include @htmlJavaScript syntax/javascript.vim
21:38:41 <KragenSitaker> ...   syn region  javaScript start=+<script[^>]*>+ keepend end=+</script>+me=s-1 contains=@htmlJavaScript,htmlCssStyleComment,htm
21:38:47 <KragenSitaker> etc.
21:38:51 <slava> heh
21:38:56 <slava> i'm still going to use jedit syntax as a base :)
21:39:03 <KragenSitaker> heh
21:39:06 <slava> the mode definitions are in xml
21:39:18 <slava> so i can give the xml lib a good workout
21:39:29 <KragenSitaker> ew
21:39:32 <slava> some modes use regexps, but its not prevalent because simpler matching operations often suffice
21:39:42 <slava> so eventually i'll use the regexp lib, which is being worked on by someone else
21:40:00 <KragenSitaker> well, I can understand not wanting to tackle vim syntax files, but if your metric of goodness is how many languages are supported, vim syntax files probably beat jedit
21:40:01 <slava> the java lib is 4098 lines of code
21:40:22 <slava> i want the factor version to be no bigger than, say, 400 lines
21:40:46 <slava> 10x code reduction over java is typical in my experience
21:40:56 <KragenSitaker> that sounds plausible --- the Factor sample you showed for the indexing problem makes it look like it's on the same level of abstraction as Python
21:41:12 <slava> yup, although its more flexible because you can extend the parser just as in forth
21:41:25 <slava> and there's a heavier emphasis on parse/compile-time meta-programming, as opposed to having too much runtime polymorphism
21:41:32 <KragenSitaker> also it has a terser syntax because it's mostly horizontal and you don't have to name variables
21:41:40 <KragenSitaker> like forth
21:41:44 <slava> its somewhat more static than python, even though its dynamically typed
21:41:53 <slava> the language and also the idioms in the library
21:42:05 <slava> but its more flexible in other ways, because hte compile stage is very flexible
21:43:39 <slava> it won't ever be as fast as forth, for obvious reasons
21:44:09 <slava> but the goal is to get as close as possible without having an overly complex optimizer
21:44:54 <KragenSitaker> well, bigForth is only about as fast as the best Self compiler
21:45:04 <KragenSitaker> so Factor could maybe be as fast as Forth
21:45:04 <slava> unlike bigforth, i do register allocation
21:45:23 <slava> i also perform specialization so factor's polymorphism can beat hand-rolled forth stuff, with passing XTs and using EXECUTE
21:45:23 <KragenSitaker> if bigForth is Forth
21:45:32 <KragenSitaker> yeah, you said
21:45:34 <slava> but generic dispatch is still a big hit
21:45:39 <slava> my arithmetic operators are generic
21:45:51 <slava> i go to great lengths to optimize out arithmetic dispatch where possible, using interval and type analysis
21:46:10 <slava> but in the general case, + * / involve two jumps
21:46:23 <slava> plus boxing/unboxing for big integers and floats
21:46:41 <slava> floats can be unboxed and stored in registers if the compiler can prove that certian values are indeed always floats
21:46:53 <slava> in forth, you just have your fp stack, that's it
21:47:12 <slava> much simpler implementation, because there is no polymorphism required
21:47:24 <KragenSitaker> heh
21:47:31 <slava> python boxes all small integer values
21:47:34 <slava> which is silly
21:47:42 <KragenSitaker> if you have a stack for every data type, you can never write a program that gets a type error
21:47:50 <slava> yeah, but you can't write generic code either
21:47:51 <KragenSitaker> that doesn't make it a good idea
21:48:02 <slava> for example, try writing a 'greatest common divisor' word in ANS forth which works with either single or double cell numbers
21:48:04 <KragenSitaker> can you opt out of integer overflow exceptions for performance-critical code in Factor?
21:48:13 <slava> you don't get overflow exceptions
21:48:18 <slava> small integers are promoted to heap-allocated big integers
21:48:23 <KragenSitaker> that's what I meant
21:48:26 <slava> you can, however, opt to use machine arithmetic
21:48:28 <KragenSitaker> can you opt out of that?
21:48:29 <KragenSitaker> ok
21:48:33 <slava> and instead of a bignum, you get rollover
21:48:46 <slava> but the idea is to let the compiler make this optimization automatically
21:48:49 <slava> by using interval analysis
21:49:02 <KragenSitaker> I'm not sure how much it matters to box small integer values in the normal case
21:49:03 <slava> for example, if you have a loop counter which is obunded by the length of an array, factor knows this will never be promoted to a bignum
21:49:14 <slava> and it will use machine arithmetic on the counter, inside the loop
21:49:15 <slava> big win
21:49:29 <KragenSitaker> in Scheme one almost never uses integer values unless one is actually doing problem-domain arithmetic
21:49:40 <slava> we have a yuv->rgb decoder
21:49:40 <KragenSitaker> it's one of the things I like about Scheme
21:49:45 <slava> which uses generic arithmetic
21:49:49 <slava> but because the yuv values come from an array of bytes
21:49:57 <slava> all the multiplications, shifts, additions, etc reduce to machine arithmetic
21:50:04 <slava> because the compiler proves that at no stage can any value exceed the word size
21:50:08 <KragenSitaker> nice
21:50:19 <slava> so the programmer doesn't have to resort to type declarations, at least in this case
21:50:37 <KragenSitaker> The APL approach can handle that kind of thing pretty well too
21:50:46 <slava> we have unboxed-float arrays
21:50:55 <KragenSitaker> like OCaml or APL
21:50:55 <slava> and vector operations on them
21:51:09 <KragenSitaker> vector operations also eliminate interpretive overhead, which can be nice
21:51:14 <slava> : v+ [ + ] 2map ;
21:51:31 <slava> HINTS: v+ float-array float-array ;
21:51:35 <KragenSitaker> oh, well, vector operations can eliminate interpretive overhead :)
21:51:44 <KragenSitaker> but not if you implement them in interpreted code!
21:51:46 <slava> the HINTS: tells the compiler to compile a specialized version
21:51:53 <slava> whcih assumes the inputs are float ararys
21:51:58 <slava> this eliminates all boxing/unboxing
21:52:05 <slava> except for one initial allocation of the new array, to hold the resulting values
21:52:09 <KragenSitaker> does it hoist the type check out of the loop?
21:52:17 <KragenSitaker> for the + dynamic dispatch I mean
21:52:17 <slava> yes
21:52:19 <slava> yes
21:52:25 <KragenSitaker> cool!
21:52:33 <slava> it becomes a tight loop which reads floats into the FPU, adds them, stores them back to memory
21:52:52 <slava> but if you pass, object arrays, it dispatches on every iteration
21:53:05 <slava> the HINTS: doesn't enforce those types, it just makes it faster if they happen to agree
21:53:37 <KragenSitaker> right
21:54:42 <slava> we do this for many sequence operations
21:54:51 <slava> 'append' is written in a generic way, it can append any two (even user-defined) sequence types together
21:54:52 <KragenSitaker> it seems like it might be better to write a yuv->rgb decoder with SSE vector primitives
21:54:55 <slava> but it has hints for string/string appends
21:55:08 <slava> KragenSitaker: yup, the compiler could do auto-vectorization after removing the dispatch :)
21:55:37 <KragenSitaker> it could.  or you could just write the vector primitives in assembly instead of teaching the compiler to do so.
21:55:44 <slava> yup
21:55:48 <slava> i haven't thought much about vectorization yet
21:55:49 <KragenSitaker> it depends on how many different pieces of code you have to vectorize.
21:55:51 <slava> i do want v+ and such to use sse eventually
21:55:58 <slava> as little as possible
21:56:22 <slava> i want to have vectorized loops on x86 and ppc with as little platform-specific asm as possible
21:56:30 <KragenSitaker> sure
21:56:31 <slava> which suggests some kind of auto-vectorization stage in the compiler
21:56:36 <slava> the analysis behind it is actually not terribly difficult
21:56:57 <KragenSitaker> but given a particular quantity of platform-specific assembly, it's probably easier to put it in library routines than in the compiler backend
21:56:58 <slava> because i use 'map', 'reduce', '2map' and so on a lot, the compiler's task is simplified by a more regular structure than a typical C or Fortran loop index clusterfuck
21:58:56 <KragenSitaker> heh
21:58:57 <KragenSitaker> sure
21:59:23 <KragenSitaker> my knowledge of compilers is fairly thin, btw, so i probably won't have much intelligent to say.  but you knew that already.
21:59:30 <slava> well, so is mine
21:59:34 <slava> this is my first compiler project
21:59:56 <slava> i've learned a lot by studying forths, lisps and to a lesser extent self and the java vm
22:00:53 <KragenSitaker> yeah, I've been following a pretty similar path
22:01:00 <KragenSitaker> I've been trying to port Self to g++ 4.x
22:01:04 <slava> heh
22:02:53 <KragenSitaker> well, I tried for a few days, then got distracted.  I did finally get it to compile, but now I need to figure out how to align its gc and object-memory expectations with the new C++ ABI
22:04:15 <KragenSitaker> and I don't really understand its gc
22:04:52 <KragenSitaker> I tried just turning it off, hoping that would get things up and minimally running, but that wasn't sufficient.
22:06:44 <KragenSitaker> Sadly I don't remember what the problem was now.
22:08:45 <KragenSitaker> So I'll probably have to rediscover it from scratch when I finally get back to that.
22:09:00 <KragenSitaker> In the mean time, I've been reading Forths in order to get more of a clue about compilers in general :)
22:09:54 <Quartus> Forth compilers are very simple, as a rule.
22:10:40 <KragenSitaker> yes; that's why I've been reading them.
22:15:32 --- part: edrx left #forth
22:22:05 <KragenSitaker> I'm not expecting them to tell me anything about parsing or crazy optimization schemes or anything like that.  Just the basics.
22:30:59 <slava> 384 lines and i haven't got to reading the xml yet.
22:31:00 <slava> hmm
23:23:28 --- quit: proteusguy (Read error: 104 (Connection reset by peer))
23:27:14 --- join: doublec (n=doublec@203-211-100-219.ue.woosh.co.nz) joined #forth
23:32:57 --- join: Off_Namuh (i=GPS@gateway/tor/x-fa2f9f4dfe2ae369) joined #forth
23:41:29 --- join: proteusguy (n=proteusg@ppp-124.120.225.88.revip2.asianet.co.th) joined #forth
23:59:59 --- log: ended forth/07.11.25