00:05:57 -!- BMeph has joined. 00:07:30 -!- RodgerTheGreat has joined. 00:07:41 hey guys, quick question- 00:07:47 -!- Corun has joined. 00:07:59 I feel like I'm taking crazy pills, because I just *KNOW* there must be an easy way to do this: 00:08:27 I want to take a 2d component vector and generate a unit vector representing the same angle. my approach is as follows: 00:08:40 double vx = blah; 00:08:48 double vy = blah; 00:09:01 double max = very close to zero, like .00001; 00:09:29 just divide by length 00:09:31 but do go on 00:09:40 if (abs(vx) > abs(vy)) {max = vx;} else if (vy != 0) {max = vy;} 00:09:57 double uvx = vx/max 00:10:03 double uvy = vy/max 00:10:06 like that 00:10:20 -!- timotiis has quit ("leaving"). 00:10:25 i don't get how that does it 00:10:40 perhaps i'm misunderstanding you 00:10:54 the length of that will most definately not be one 00:11:07 because one of those will be 1, and the other nonzero 00:11:11 I understand that 00:11:24 but that works? 00:11:26 so "unit vector" was probably unclear 00:11:32 probably 00:11:33 that does essentially what I want 00:12:07 i see :P 00:12:07 you're using the max (L^infinity) norm... 00:12:14 umm 00:12:31 ah 00:12:31 right 00:12:33 heh :D 00:12:40 but since calculating the length of one of these vectors would involve an application of the pythagorean theorem, it doesn't seem like that approach is necessarily any faster or simpler 00:13:45 I suppose a better way to phrase this question is "is the way I'm currently doing this astoundingly stupid?" 00:14:01 well, as oerjan said, it's not the cartesian unit vector 00:14:02 um what kind of length do you want to be 1 in the final vector? 00:14:09 so it's not stupid, it's wrong 00:14:13 -!- sebbu has quit ("@+"). 00:14:27 or is cartesian the superset for n-norm? 00:14:32 i don't really know anything. 00:14:57 also even if you did want L^inf, (cartesian = L^2) you would want to divide on abs(max), not max 00:15:25 hm. 00:15:29 ah, right 00:16:14 does this mean infinity is even? :D 00:16:26 ah yes, it appears I'm already doing it that way in my code. I simply forgot some abs()es in my example above 00:16:41 (don't you need abs for odd exponent norms only) 00:16:58 (i'm not sure about anything, and i have my math matriculation exams tomorrow :DDDDDDDDDDD) 00:17:14 (i guess i should sleep, it's 1:16 or soemthing) 00:17:54 RodgerTheGreat: especially for 2d, you need the unit vector anyway for most things 00:18:03 so why not calc it 00:18:14 I just know a modicum of trig, physics and calculus that I really absorbed during school and stumble my way through the math with a pencil and graph paper when I need to do things for games and the like 00:18:37 wouldn't my result be off by a constant multiple this way? 00:18:48 well, not really 00:18:58 because you could just divide by that constant otherwise 00:19:12 and have a non-pythagorean unit vectorizer 00:19:15 er, your _original_ vector is off by a constant multiple 00:19:31 er, scalar multiple 00:19:43 yes 00:20:01 i thought constant meant... constant 00:20:10 and to get a unit vector you have to find that multiple (the length) and divide by it 00:20:43 good start, oerjan, now to confuse him with awesome math :-) 00:21:06 ...not gonna? :< 00:21:09 my approach represents the correct angle, but is clearly longer than the unit vector 00:21:29 RodgerTheGreat: as was the original, ofc 00:21:45 yeah, I follow you 00:21:52 if you only need a _canonical_ vector in the same direction, any length will be fine 00:22:18 so what's computationally cheaper- the pythagorean theorem, or my if-then-else? 00:22:29 oerjan: yeah, that's why it's working for my purposes 00:22:35 in fact it might be simpler to use L^1: abs vx + abs vy 00:22:38 RodgerTheGreat: yours, but i don't really see its point 00:23:00 RodgerTheGreat: in that case, i suggest Identity 00:23:14 oerjan: ah- that's an excellent idea 00:23:30 RodgerTheGreat: what do you need this for? 00:23:50 oklokok: I do calculations of this form in several places for a game I'm working on 00:24:00 for what purpose? 00:24:13 if you have a java compiler installed, I can show you the source 00:24:25 oklokok: just for fun. I'm on vacation, so I'm entertaining myself 00:24:26 preferably tell me quickly, for i should go :P 00:24:29 -!- GregorR has joined. 00:25:06 RodgerTheGreat: i'd say just calculate the square root, you can get a nice approximation with a constant number of steps 00:25:07 it's kinda a cancer simulation, although it's not biologically accurate at all 00:25:33 there are tricks for getting accuracy up to a one hundreth with just a few divisions 00:25:36 * oklokok searches 00:26:29 hmm, actually i don't have any recollection where i saw that 00:27:11 essentially, it simulates a large pile of cells that can move around, bounce off one another and do the usual physics-engine stuff, and you control a swarm of infected cells that can capture healthy cells, all while being harassed by immune-system cells. 00:27:51 well, l^1 looks very *square*, in at least two meanings of that word 00:28:18 what do you use the unit vector for? 00:28:27 yeah it's the taxicab metric 00:29:04 in one case, I'm positioning the nucleus of a moving cell based on its current velocity 00:29:14 ah 00:29:21 you don't want l^1 then 00:29:33 (although that's actually a poor example, because there I divide by the defined terminal velocity of the cell) 00:29:46 because the thingie will move on a square around the cell 00:29:51 *the nucleus 00:29:57 I just run into this type of calculation from time to time 00:30:10 the velocity is a vector - you don't need to turn it into a unit vector to add it to position 00:30:30 oerjan: i guess the cell can move at any speed? 00:30:40 RodgerTheGreat: just store the damn unit vector 00:30:45 I store and manipulate vectors in unit format, not polar 00:30:49 you'll need it for everything anyway 00:31:09 i am talking cartesian format 00:31:12 polar isn't that useful for games 00:31:23 we're all talking cartesian 00:31:26 new_pos = old_pos + time_diff * velocity 00:31:27 oklokok: really depends on the game 00:31:47 oerjan: yes, that's how I do it 00:31:48 RodgerTheGreat: if there's drawing / moving, cartesian is the way to go. 00:32:08 I have a fairly good understanding of this stuff in an applied sense 00:33:05 oh, god, i really need to go 00:33:14 but have fun with your cells! -> 00:33:27 yeah, I 00:33:42 I'm going to have to get going myself, but thanks for the suggestions, guys 00:34:18 -!- RodgerTheGreat has quit. 00:57:41 -!- Quendus has joined. 00:57:45 \o/ 01:03:33 -!- oerjan has quit ("Good night"). 01:33:53 -!- Corun has quit ("This computer has gone to sleep"). 01:37:42 -!- jix has quit ("CommandQ"). 01:39:25 -!- CakeProphet has joined. 02:50:42 -!- calamari has joined. 02:50:51 hi 03:59:41 -!- CakeProphet has quit ("haaaaaaaaaa"). 04:16:05 pikhq: how's your os project going? 04:21:18 -!- immibis has joined. 04:26:26 calamari: Going decently. 04:26:30 Although not much has happened yet this week. . . 04:26:30 -!- ohgrfilth has joined. 04:27:06 -!- ohgrfilth has left (?). 04:32:21 -!- immibis has left (?). 04:32:21 -!- immibis has joined. 04:32:22 -!- immibis has left (?). 06:16:59 -!- adu has joined. 06:41:56 -!- calamari has quit ("Leaving"). 07:59:59 -!- clog has quit (ended). 08:00:00 -!- clog has joined. 08:02:48 -!- BMeph has quit ("calls it a night"). 08:43:19 -!- adu has quit (Remote closed the connection). 09:27:27 -!- oerjan has joined. 09:32:56 -!- slereah_ has joined. 09:32:56 -!- slereah__ has quit (Connection reset by peer). 09:36:15 -!- olsner has quit ("Leaving"). 09:41:00 -!- slereah_ has quit (Read error: 104 (Connection reset by peer)). 09:41:15 -!- slereah_ has joined. 11:22:08 Deewiant, changed to a hash library, no idea if it is the best one, but licence is nice and it's simple to use, still faster than ccbi at mycology though 12:45:22 Deewiant, also the ccbi from you, is broken it seems, it does not pass mycoterm 12:45:29 "\E[H\E[2JC was called, the screen should have cleared." 12:45:36 and no clearing 12:45:51 NCRS work however 12:45:55 yeah, the curses stuff is messed up 12:45:59 I don't know how it should be done 12:46:10 or rather, it doesn't use curses 12:46:15 but the ECMA-48 CSI sequences 12:46:32 they worked on cygwin, I think 12:48:16 well.... 12:48:24 Deewiant, you should use terminfo 12:48:27 AnMaster: btw, there's a GDC-compiled version of CCBI up at iki.fi/deewiant/ccbi 12:48:35 I don't know how that stuff works 12:48:43 man 5 terminfo 12:48:59 I just copied RC/Funge's implementation 12:49:05 and, just use curses to do it 12:49:06 :) 12:49:11 curses will use terminfo databse 12:49:13 database* 12:49:15 yeah, that's probably the best option 12:49:29 Deewiant, not sure about that, but it is the *easiest* 12:49:47 there is some libtermcap if you want to do it yourself iirc, or maybe it was libterminfo 12:50:00 anyway termcap is older name for same thing iirc 12:50:13 there probably aren't D bindings for that and I can't be bothered to do that since I've got working curses 12:50:30 Deewiant, you need special bindings? 12:50:41 nothing 'special', no 12:50:43 you can't just use a C header file like you can in C++? 12:50:45 just define extern(C) function 12:50:48 nope 12:50:54 D doesn't use .h files 12:50:58 terminfo is an improved system on termcap iirc 12:51:04 oerjan, something like that 12:51:11 AnMaster: anyhoo, what are the timings like for that GDC-compiled one 12:51:15 I never messed with terminfo/termcap other than from bash anyway 12:51:18 just to see if PaX makes that big a difference 12:51:24 and in bash I just use the tput command 12:51:27 i don't think they are particularly backwards compatible 12:51:41 Deewiant, iirc slightly less as I told you? 12:51:48 wasn't a big difference 12:51:51 AnMaster: you haven't run that one 12:51:57 err link then? 12:52:02 AnMaster: I said it above 12:52:11 ah 12:52:13 right 12:52:52 hmm, I can't use curses, right 12:52:53 real 0m1.623s 12:52:53 user 0m0.477s 12:52:53 sys 0m0.053s 12:52:59 Deewiant, you can't? 12:53:04 -!- atsampson has quit (Read error: 104 (Connection reset by peer)). 12:53:14 Deewiant, so about 0.1 second difference 12:53:17 AnMaster: curses needs to init itself 12:53:24 AnMaster: that was with GCC 4.1.2, -O3 12:53:25 -!- atsampson has joined. 12:53:31 but PaX markings are good anyway, because it allows things to be more secure :) 12:53:36 when running under a hardened kernel 12:53:56 AnMaster: so since curses needs to init itself, I'd have to init it for the whole program and then use curses for all output 12:54:06 less risk for stuff like buffer overflows and such 12:54:15 Deewiant, ah ok 12:54:19 because TERM doesn't have any "initialize" instruction, but NCRS does 12:55:40 hmm 12:55:49 tput uses curses it seems 12:56:15 but it doesn't clear the screen at the start or such 12:56:21 like NCRS do 12:57:00 initscr() does that 12:57:13 ok, I guess tput doesn't do that part of ncurces 12:57:32 hrm, you can't really do anything if you haven't done initscr 12:57:47 -!- oerjan has quit ("dnorf"). 12:57:55 well it just gets terminfo stuff and outputs capability 12:58:03 "The initscr() function also causes the first refresh operation to clear the screen." 12:58:13 Deewiant, well, no idea then 12:58:22 tput doesn't clear the screen 12:58:24 man tput 12:59:07 hmm, term.h 12:59:49 /usr/include/ncursesw/term.h ? 13:00:04 probably 13:00:38 $ diff /usr/include/term.h /usr/include/ncursesw/term.h 13:00:38 47c47 13:00:38 < #include 13:00:38 --- 13:00:38 > #include 13:00:38 heh 13:01:28 Deewiant, btw can a fingerprint be loaded several times? 13:01:32 sure 13:01:40 say 1) load fingerprint 2) load some other 3) load it again 13:01:47 and for ccbi, would that call intscr() again 13:01:48 or even just 1) load fingerprint 2) load it again 13:02:00 for NCRS 13:02:07 yes, it probably would 13:02:17 Deewiant, it probably shouldn't 13:03:11 so what should one do after endwin()? 13:03:20 and hmm, actually it won't 13:03:32 AnMaster: since initscr() is only called when the instruction I is called 13:03:38 nothing happens when loading NCRS 13:05:07 * AnMaster notes having one malloc / cell is stupid, but, oh well 13:05:56 it's still about twice as fast as ccbi even for apps without fingerprints. 13:05:57 :) 13:06:27 weird, now pasting started working in irc client again 13:06:30 * AnMaster shrugs 13:06:44 Deewiant, btw, does D use a garbage collector? 13:06:58 yes, built-in 13:07:30 not boehm then when using gdc? 13:07:37 no 13:07:44 Deewiant: what age are ya? 13:07:49 oklokok: 20 13:07:54 considering boehm is used for the gcj thing iirg 13:07:56 iirc* 13:08:21 Deewiant: math matriculation exams were just now, so i was just checking whether you happened to do that too 13:08:57 nope 13:09:55 prolly not, programmers tend not to fail enough to be at high school at the age of 20 13:10:02 heh 13:10:14 * oklokok hopes he's not insulting too many here 13:11:51 is this thue-day, unlambda-day or brainfuck-day? 13:12:06 mycotemp.tmp: ASCII text 13:12:06 mycotmp0.tmp: DBase 3 data file (590422062 records) 13:12:13 Deewiant, wtf did it write to mycotmp0.tmp 13:12:27 oh? looks like part of a funge program 13:12:28 AnMaster: just some binary 13:12:31 I think 13:12:34 can't remember 13:12:48 Deewiant, also should mycotemp.tmp have a ending newline? 13:13:06 I don't know, probably not if it doesn't have one and Mycology is happy :-P 13:13:08 mycotmp0.tmp got an ending newline, mycotemp.tmp does not 13:13:10 they're just tmp files 13:13:19 Deewiant, that it doesn't remove afterwards heh 13:13:27 yeah, because it can't be done portably 13:16:35 whoo down with 0.2 seconds thanks to some tricks :) 13:16:57 (not really fair to compare, as it's a trick you can do on any binary) 13:17:03 called prelinking 13:17:16 oh wait this is a debug build 13:18:15 ok down with another 0.2 now, almost as fast as with static array for fungespace 13:18:21 real 0m0.348s 13:18:21 user 0m0.108s 13:18:21 sys 0m0.020s 13:18:24 cfunge :) 13:18:37 * AnMaster goes to fix y instruction now 13:19:24 AnMaster: how do you do output, btw 13:19:28 I mean just basic , 13:19:42 , = putchar((char)a); 13:19:48 . = printf("%ld ", a); 13:20:03 and I flush after each put char 13:20:07 I probably shouldn't do that 13:20:18 would make it faster to just flush at input or newline 13:20:22 probably 13:20:35 Deewiant, what do you think? 13:20:35 I need to have an if branch at each ',' because of the TRDS fingerprint 13:20:45 that fingerprint really BURNS MY ASS 13:20:54 Deewiant, oh? why? I don't understand what TRDS is really 13:20:57 stupid fool had to write the spec for it and didn't implement it even half properly 13:20:59 travel in time it says 13:21:01 aye 13:21:08 but what does it mean 13:21:10 so you can go back in time, say, 200 ticks 13:21:16 then modify funge-space there so stuff happens differently 13:21:31 ah 13:21:57 sounds like that think ais[0-9]+ (can't remember actual nick) talked about 13:22:00 for intercal 13:22:03 MAYBE statement 13:22:07 that was such a mess in C 13:22:14 using setjmp and what not 13:22:39 Deewiant, so I'm not going to implement TRDS then 13:22:42 :) 13:22:53 I suggest you don't 13:23:00 it's /hard/ 13:23:05 to get it to work properly 13:23:10 I will do null, but anyway first I'll get y correct 13:23:18 I have 50-line comments in CCBI explaining some TRDS-related stuff 13:23:21 and proper command line parsing 13:23:23 and I'm still not sure I've got it right 13:23:26 using getopt of course 13:23:35 heh, null is just the default 13:23:45 Deewiant, indeed, but I got a question 13:23:46 say: 13:24:16 you load "PRINT", then load NULL, then unload NULL 13:24:27 should instructions now map to PRINT again 13:24:28 ? 13:24:39 yep 13:24:55 so you need to keep some special instruction stack for each char to get loading right 13:25:01 yep 13:25:19 also, is it possible to do load PRNT, then QUUX then unload PRNT 13:25:24 that is unload out of order 13:25:35 and what should happen in such cases 13:27:03 just what you expect 13:27:14 Deewiant, I got no idea what would happen then 13:27:15 if PRNT defines ABC and QUUX defines ABCDE 13:27:20 yep 13:27:22 then after that DE are bound to QUUX and ABC to PRNT 13:27:39 and then if you unload QUUX 13:27:47 DE are bound to PRNT 13:27:49 err 13:27:51 what? 13:27:55 :-P 13:28:00 go over it, draw a diagram or two if it helps 13:28:26 1) load PRNT 2) load QUUX 3) *UN*load PRNT 13:28:38 you must have misunderstood what I meant? 13:28:43 no, I believe I was quite correct 13:28:46 err 13:28:48 okay 13:28:53 PRNT defines A, B, and C 13:28:55 yep 13:29:00 QUUX defines A, B, C, D, and E 13:29:05 you load PRNT 13:29:12 A, B, C are bound to PRNT's funcs 13:29:18 you load QUUX 13:29:19 so far I'm with you 13:29:24 ABCDE are bound to QUUX's funcs 13:29:28 yep 13:29:30 that I got 13:29:31 unload PRNT 13:29:36 so, unload ABC 13:29:43 so DE remain bound to QUUX's funcs 13:29:51 so wait, it unloads ABC even though those are bound to something else? 13:30:01 ABC become bound to PRNT's functions because that was what they were bound to before 13:30:07 yep 13:30:07 i.e. 13:30:10 A has a stack 13:30:15 aye 13:30:17 [PRNT, QUUX] 13:30:24 with the top on the right 13:30:29 so you unload PRNT 13:30:30 yep 13:30:33 you pop one off the stack 13:30:37 you're left with [PRNT] 13:30:50 DE still have a stack of the form [PRNT, QUUX] 13:31:07 because when unloading PRNT, you only popped from ABC. 13:31:13 then the stack should end up as [, QUUX] possibly? and then getting compacted to be just [QUUX]? 13:31:43 following the stack of A: 13:31:44 [] 13:31:48 load PRNT: [PRNT] 13:31:52 load QUUX: [PRNT, QUUX] 13:31:56 unload PRNT: [PRNT] 13:32:07 unload anything that defines A: [] 13:32:10 unload PRNT: [PRNT] <-- that is where I'm not sure you are right 13:32:19 I am right 13:32:28 when you unload PRNT, what happens is essentially: 13:32:34 "aha, PRNT defines A, B, and C" 13:32:46 "let's go pop 1 off the instruction stack from A, B, and C" 13:32:57 it doesn't matter whether the instruction on top of the stack is the one defined by PRNT 13:33:16 Deewiant, is that what the standard says? 13:33:17 we could add a third fingerprint, FOOB 13:33:20 which defines A 13:33:28 so back at load QUUX: [PRNT, QUUX] 13:33:32 unload FOOB: [PRNT] 13:33:39 Deewiant, sorry bbl, phone 13:33:46 and yes, that's what the spec says. 13:45:14 Deewiant, but you can't unload a non-loaded fingerprint right? 13:45:34 sure you can 13:45:43 it should reflect then shouldn't it? 13:45:58 nope 14:00:08 meh, now I'm using term.h functions and it's still not working 14:04:34 -!- Corun has joined. 14:12:04 man, this sux. I'm going to just comment out the TERM fingerprint on Posix. 14:17:01 Deewiant, nah :/ 14:17:17 AnMaster: figure out how to make it work, I can't and won't bother. 14:17:19 if I do TERM I will do it the right way 14:17:30 but I got other issues to fix first 14:17:32 what's the 'right way'? 14:17:38 I'd love to know :-P 14:17:40 Deewiant, using terminfo 14:17:46 yeah, that's what I tried 14:17:51 I will research how tput does it 14:17:58 -!- timotiis has joined. 14:19:21 it's a part of ncurces 14:19:29 err spelling 14:20:43 Deewiant, if you want I'll wgetpaste tput's source 14:20:53 nah, can't be bothered now 14:20:55 http://rafb.net/p/v2UBD448.html 14:20:56 there 14:39:05 -!- whice has joined. 14:39:24 hi all 15:04:00 -!- RedDak has joined. 16:01:04 Deewiant, yes now cfunge is definitly faster than ccbi even when I compile to 32-bit code 16:02:46 I realized that one thing is slowing me down by about 33% for all accesses to funge-space, and that is mini-funge 16:03:03 because then each IP needs to keep a pointer to know what its funge-space is 16:03:14 instead of all using the same global 16:06:14 and that can't really be helped without removing mini-funge entirely :-/ 16:26:03 Deewiant: 16:26:05 BAD: 0y pushes wrong stack size 16:26:09 what exactly does that mean 16:27:04 it called 0y and expected to find the correct stack size in the heap of stuff that y pushes 16:27:17 I suspect that you push nothing for 0y 16:27:21 which would be incorrect 16:27:34 * AnMaster checks, I do push things for 0y 16:27:44 then you might be pushing the new stack size instead of the old one 16:28:13 ah very likely, I push the stack size at the point of pushing stack size 16:29:03 because then each IP needs to keep a pointer to know what its funge-space is 16:29:03 instead of all using the same global 16:29:04 hm 16:29:18 * AnMaster does pass fspace around a lot, but that could be fixed 16:29:26 yes I'll make it a global 16:29:29 nice idea 16:29:30 I tested, having them all refer to the global fungespace instead of dereferencing a pointer speeds some stuff by about 30% 16:30:46 Deewiant, anyway another thing that will slow down 32-bit code: normal calling convention passes arguments on the stack 16:30:59 AMD64 ABI pushes quite a few in the registers 16:31:18 aye 16:31:54 and of course the function pointer thing for instructions doesn't allow them to be inlined 16:32:04 yes, that's the biggest performance penalty 16:32:13 practically everything goes through a pointer 16:32:13 oh and y breaks all my abstractions for stackstack 16:32:39 I need to code some way to access non-top stacks from the y code :( 16:32:41 * AnMaster sighs 16:32:49 messes up my clean interface 16:33:14 another thing, 16:33:15 1 vector containing the least point which contains a non-space cell, relative to the origin (env) 16:33:22 is that relative to storage offset? 16:33:29 or relative to (0,0)? 16:33:38 I'm not sure... 16:33:47 Deewiant, what does ccbi do for it? 16:33:49 but the storage offset at that point should be (0,0) anyway 16:33:51 and does mycology test that 16:33:55 Deewiant, yes of course 16:33:56 can't be bothered to check, and no, probably not 16:34:06 but it is undefined in the standard? 16:34:10 probably not 16:34:14 * AnMaster wonders 16:34:24 just check the spec yourself :-P 16:34:48 I looked at them 16:34:50 That the time is 00 : 08 : 1128682830 16:34:59 'woops' 16:35:04 I wonder, why does passing a dummy value of 0 cause that 16:35:09 Deewiant, I know, it's // TODO 16:35:10 :P 16:35:27 it's still odd 16:36:51 probably because the befunge expects 2 values there 16:37:01 if you're pushing only one zero that is 16:37:13 # 1 cell containing current ((year - 1900) * 256 * 256) + (month * 256) + (day of month) (env) 16:37:13 # 1 cell containing current (hour * 256 * 256) + (minute * 256) + (second) (env) 16:37:14 ? 16:37:23 I push one for each of those 16:37:27 then beats me 16:37:36 ah, no, obvious? 16:37:40 err? 16:37:46 or no 16:37:48 for the date it might have been 16:37:54 That the year is 1900 16:38:03 yeah, that makes sense 16:38:04 yes right, but the time I don't get 16:38:33 don't know, read the befunge to see what it does and figure it out :-P 16:38:41 Deewiant, I'm not that mad 16:38:45 I just ask the author 16:39:00 I don't care why it does that 16:39:09 you give it incorrect values and it produces incorrect output :-P 16:40:48 \f1+:*/:f1+:*%\f1+:*/ 16:40:53 looks like the code that calculates it 16:43:27 mhm 16:43:56 Deewiant, I stopped passing fungespace pointer around, no noticable speed difference 16:44:46 still around 0.5 seconds both before and after (for debug version, I guess optimized build could make a difference 16:47:58 and around 0.3 with debug info 16:59:25 That the day of the month is -244 16:59:25 That the month is -253 16:59:25 That the year is 109 16:59:26 wtf 17:02:33 ah better 17:02:59 Deewiant, a bug in mycology: 17:03:01 That the environment variables are: 17:03:01 ÿÿ´ 17:03:07 it is valid to run with a clean env 17:03:16 you can do it using env -i in front of the program 17:03:41 err wait 17:03:46 wtf 17:04:02 I think mine does something strange on outputting \0 17:06:06 Deewiant, another question: should time in y be local time or UTC= 17:06:09 s/=/?/ 17:06:16 not specified, I don't think 17:06:39 ccbi does UTC heh 17:06:44 easiest indeed 17:06:45 yep 17:06:50 just time and gmtime needed then 17:07:02 there's a fingerprint which allows both UTC and local 17:07:06 TIME I think 17:07:14 (negative year problem, turns out the result of tm is already in years since 1900....) 17:14:02 That the command-line arguments were: [ null "/home/arvid/bashfunge/trunk/mycology/mycology.b98" "./cfunge08" null ] 17:14:05 that looks wrong 17:14:08 hehe 17:14:12 indeed it does :-P 17:14:12 * AnMaster changes order 17:14:25 ./cfunge08 isn't supposed to be there btw 17:14:38 oh? 17:14:57 only mycology.b98 17:15:20 That the command-line arguments were: [ null "./cfunge08" "/home/arvid/bashfunge/trunk/mycology/mycology.b98" null ] 17:15:23 slightly saner 17:15:37 Deewiant, with full path I assume? 17:15:50 doing path splitting would be insane 17:16:13 because it was called with full path 17:16:24 with whatever it was called, I guess 17:16:40 Deewiant, no ending null? 17:16:43 I guess the idea is that if you open the file with the given name then it should be the same file 17:16:53 That the command-line arguments were: [ "/home/arvid/bashfunge/trunk/test/mycology.b98" null ] 17:16:53 well, you've got too many nulls there :-P 17:16:56 is from ccbi 17:17:07 only with env -i 17:17:17 and I'm not going to figure out why 17:17:19 Deewiant, ? 17:17:31 weird 17:17:39 AnMaster: if you run without an empty environment there won't be an ending null there 17:18:09 actually, depending on how D pass stuff to main() that may make sense 17:18:23 how's that 17:18:36 because, both these are valid main() prototypes in C: 17:18:40 int main(int argc, char *argv[]) 17:18:40 and 17:18:49 int main(int argc, char *argv[], char*envp[]) 17:18:55 uh, no 17:18:56 not sure of name for the latter 17:18:58 the latter is only posix 17:19:05 if that 17:19:11 I don't know what it is but it's not standard C :-P 17:19:16 ah 17:19:19 well 17:19:43 anyway possibly if they follow each other in memory that could mean some off by one error on the part of D 17:19:54 D is fine, it's not that 17:20:03 because D doesn't use null-terminated strings 17:20:17 D arrays are (length,pointer) pairs 17:20:22 and main is int main(char[][] args) 17:20:24 * AnMaster sighs 17:20:45 well popping and pushing 0gnirts are harder then 17:20:49 it's really easy in C 17:20:58 not really, no 17:21:03 or, well 17:21:06 harder, yes 17:21:08 but not hard :-P 17:21:15 for (ssize_t i = len; i >= 0; i--) 17:21:16 StackPush(str[i], stack); 17:21:22 that is my StackPushString 17:21:52 void pushStringz(char[] s) { 17:21:52 ip.stack.push(0); 17:21:52 pushString(s); 17:21:52 } 17:21:52 void pushStringz(char* s) { 17:21:54 if (s) { 17:21:57 while (*s++){} 17:21:59 while (*s) 17:22:02 ip.stack.push(cast(cell)*s--); 17:22:04 } else 17:22:07 ip.stack.push(0); 17:22:09 } 17:22:13 AnMaster: you're missing the calculation of len, which is a call to strlen 17:22:13 hum? 17:22:24 Deewiant, it is passed as a argument to the function 17:22:25 that's mine, since you were obviously asking :-P 17:22:30 to allow pushing several in one row 17:22:33 AnMaster: ah 17:22:39 one go* 17:23:15 Deewiant, and allows potential for cashing string length in case I push the same several times or such 17:23:18 ;P 17:23:32 I only use pushStringz with fingerprints, though 17:23:41 nowhere in the normal code 17:23:49 mhm 17:23:58 my pop string is more complex 17:24:10 it uses some nice fast extensible strings things from boehm-gc 17:24:26 mine just uses normal D strings :-P 17:24:32 http://rafb.net/p/nZCGyC10.html 17:24:47 but hey, if you feel like more benchmarking, http://users.tkk.fi/~mniemenm/files/befunge/interpreters/ccbi/ccbi_linux.zip 17:25:01 Deewiant, what's new in that one? 17:25:02 CORD_ec? ew 17:25:16 Deewiant, yes? what about it? nice thing from boehm-gc 17:25:19 AnMaster: for one thing it has a --disable-fprints command line argument :-) 17:25:27 AnMaster: what does it mean? looks like too many abbreviations in one :-P 17:25:27 Deewiant, hahaha 17:25:42 (/* Extensible cords are strings that may be destructively appended to. */ 17:25:43 err 17:25:52 the ( was mispaste 17:25:52 right 17:26:03 * Cords are immutable character strings. A number of operations 17:26:03 * on long cords are much more efficient than their strings.h counterpart. 17:26:07 from cord.h 17:26:32 Deewiant, cord isn't an abbrev 17:26:46 cord and string are both think long objects :P 17:26:51 yeah 17:26:56 just wondering why it's called cord and not just string 17:27:03 because it isn't a string 17:27:04 since, after all, "cords are [...] strings" :-P 17:27:07 it's faster in some cases 17:27:22 they look like strings to me 17:27:30 * The following are reasonable applications of cords. They would perform 17:27:30 * unacceptably if C strings were used: 17:27:30 * - A compiler that produces assembly language output by repeatedly 17:27:30 * concatenating instructions onto a cord representing the output file. 17:27:44 look like D strings to me, then 17:27:45 it is such a case I do here, adding one char at a time 17:28:02 nop 17:28:22 typedef struct CORD_ec_struct { 17:28:22 CORD ec_cord; 17:28:22 char * ec_bufptr; 17:28:22 char ec_buf[CORD_BUFSZ+1]; 17:28:22 } CORD_ec[1]; 17:28:54 I really don't care how they're implemented 17:29:02 they're convenient abstractions to avoid having to mess with strcat and co 17:29:07 that's all I need to know :-P 17:29:09 yep 17:29:14 and uses boehm-gc 17:29:26 I think they wouldn't work without boehm 17:30:52 so how does the new CCBI run for you 17:31:06 mycology piped to dev/null takes 0.36 seconds on my laptop 17:32:19 real 0m1.602s 17:32:21 better 17:32:50 odd that it's that slow 17:35:10 how about without fingerprints? :-) 17:35:24 replace all ( with r? 17:35:33 won't it fail then due to no popping? 17:36:21 no, I mean use ccbi -P 17:36:26 or ccbi --disable-fprints, same thing 17:36:52 real 0m1.110s 17:36:53 then 17:38:46 alright, you can do some profiling for me 17:39:05 iki.fi/deewiant/ccbi, run it on mycology piped to dev/null and send me gmon.out :-) 17:39:06 why? I'm busy 17:39:16 I want to win over you 17:39:17 so no 17:39:19 :-D 17:39:20 not yet 17:39:23 you've already won 17:39:28 I can't be bothered to optimize any more 17:39:33 unless there's an obvious bottleneck on your machine 17:39:49 at this point, all I can do is remove features or make the code so fugly that it's not worth it 17:40:08 heh I'll see 17:41:03 thing is that there's nothing obviously slow that I can find 17:41:19 hm 17:41:38 it's just that some things are called 300 000 times - through function pointers, even 17:41:51 and if they take 1 microsecond each then yes, it'll take 0.3 seconds :-P 17:41:57 * AnMaster got time down for cfunge another 0.05 seconds using -fbranch-probabilities 17:42:05 17:42:16 profiled to match mycology 17:42:17 ;D 17:42:20 :-P 17:42:38 Deewiant, I'm sure I can optimize hash function I use for mycology performance too 17:42:40 I think GLFunge98 was already faster than CCBI, actually 17:42:49 AnMaster: how've you implemented funge-space now? 17:42:49 and even, my k isn't as optimized as yours is 17:42:55 hah, k :-D 17:43:06 none of those extra-optimized k ones are called in mycology 17:43:12 so it's actually a slowdown 17:43:13 Deewiant, using a hash library, key is a position struct 17:43:16 to have that switch case there 17:43:36 AnMaster: I see 17:44:01 AnMaster: I once tried that thing I was talking about, have the upper 32 bits of a 64 bit int be the y coordinate and the lower the x coordinate 17:44:10 AnMaster: it was quite a bit slower than my current hash table of hash tables -thing 17:44:12 Deewiant, I allocate the data for the cells (as it uses pointers for both position and data) in chunks of 512 entries 17:44:21 may mean some overhead but faster at load time 17:44:29 yeah, that helps 17:44:38 CCBI's runtime on mycology is mostly load time 17:44:43 at least on my computers, don't know about yours 17:44:51 Deewiant, initial entries in hash table is set to slightly more than mycology needs 17:44:52 maybe PaX isn't friendly to function pointers 17:44:53 about 1000 more 17:44:54 or so 17:45:04 Deewiant, no clue, read about PaX on wikipedia 17:45:37 Deewiant, that is I call hash creation with initial size set to slightly more chars than is in mycology 17:45:57 I have no control over that 17:46:07 heh, your problem 17:46:09 D probably allocates in much smaller chunks internally 17:46:20 well, I could argue that that's a huge waste of memory on most befunge programs 17:46:43 everywhere where I have constants in CCBI, they're set to 'typical' values and not 'mycology' values :-P 17:46:45 Deewiant, also, mine is definitely optimized for AMD64, it is slower at x86 but not much, but parameter order is optimized to pass as many parameters as possible in the registers 17:47:37 of course, most functions can pass all parameters in the registers here :) 17:47:43 with any order 17:47:45 yep, that helps 17:48:08 Deewiant, and I use gcc __attribute(())__ sometimes 17:48:19 mostly because it allows me to get better warnings 17:48:20 meh, overoptimization 17:48:34 like __attribute__((warn_unused_result)) 17:48:35 :P 17:48:41 to ensure correct code 17:48:57 some other both gives better warnings and better code, like nonnull 17:49:07 and probably allows it to optimize better 17:49:12 as well as give good warnings 17:49:45 well, the DMD compiler frontend sucks, so any D-specific optimization is pretty much out of the window for my code 17:49:53 any optimization that GCC does will be done at asm level 17:50:07 any significant optimization, that is 17:50:16 hehehe 17:50:25 you have a huge advantage there 17:50:30 * AnMaster goes to mark some pure functions 17:50:30 even though we use the same backend 17:50:32 :P:P 17:50:56 I honestly don't care 17:51:05 Deewiant, anyway if you use gdc you would get same backend 17:51:09 of course, if you're performance tuning as much as you are, and writing in C, you will be faster :-P 17:51:12 AnMaster: that was GDC 17:51:13 and should get about same level of optimization 17:51:16 AnMaster: like I said, same backend 17:51:21 but no, it's not the same level 17:51:31 think about stuff like const, which I suppose you use somewhere 17:51:35 or all those __attribute__ things 17:51:41 they're completely lost when translated to asm 17:51:49 Deewiant, hm now it is faster, down at 0.9 seconds for ccbi 17:51:49 weird 17:52:06 that blender render completed? ;-P 17:52:16 Deewiant, nah, that finished around noon today 17:52:38 Deewiant, anyway I do NOT use __attribute__ for gaining speed 17:52:43 I use it for correct code 17:52:47 it doesn't matter 17:52:48 warn about unused results 17:52:50 just like const 17:52:51 that kind of stuff 17:53:00 Deewiant, yes doesn't D have const? 17:53:00 const is used for correctness of code 17:53:06 AnMaster: not in the same way C does 17:53:14 AnMaster: only for compile-time constants 17:53:16 I'm using const when I can, for correct ness 17:53:21 correctness* 17:53:21 but my point is 17:53:26 you use it for correctness 17:53:30 no idea if gcc optimize on it 17:53:33 but of course it's a potentially big optimization help as well 17:53:50 Deewiant, as is the C99 restrict keyword (that I'm not using, yet) 17:53:56 yep 17:54:08 though not sure about correctness for restrict 17:57:31 Deewiant, also, no idea if you can use out parameters in D? 17:57:34 like say: 17:57:40 void x(out int x) 17:57:42 void changemyparameter(char * foo); 17:57:48 so it opterates on the thing in place 17:57:52 operates* 17:58:31 like said above, 'out' exists 17:59:00 out and in? or just out? 17:59:53 out, in, and inout 18:00:12 -!- jix has joined. 18:00:37 ah 18:02:19 -!- jix has quit (Client Quit). 18:02:49 -!- jix has joined. 18:03:47 Deewiant, real 0m0.374s 18:03:48 :D 18:04:14 -!- jix has quit (Client Quit). 18:04:14 * AnMaster changes back to debug version to work on fingerprints 18:04:50 -!- jix has joined. 18:12:47 Deewiant, by the way my debug build takes about 0.6 seconds at mycology 18:14:19 AnMaster: got a copy of your binary? to see how fast it is here 18:34:55 Deewiant, I think I know about ccbi's env -i problem 18:35:00 or maybe rather mycologys 18:35:04 consider the stack 18:35:18 with env -i, it's null null null null 18:35:18 it would push \0\0 at the end of the environment right? 18:35:22 I think 18:35:26 Deewiant, exactly 18:35:33 and mycology fails to handle that 18:35:43 is that ambiguous, though 18:35:47 it is 18:35:50 because you can't know 18:35:59 indeed 18:36:06 so complain at the spec 18:36:23 Deewiant, if you were to redesign that bit, what would you suggest? 18:37:05 I'd suggest losing 0gnirts and using gnirts instead 18:37:13 hm interesting 18:37:14 never ambiguous 18:37:19 and then you can have nulls in strings 18:37:20 not backwards compatible 18:37:23 Deewiant, indeed 18:38:50 BAD: : on empty stack doesn't make stack size 2, says y 18:38:50 GOOD: \ on empty stack makes stack size 2 according to y 18:39:00 both push 2 according to gdb 18:39:01 :/ 18:39:12 then y fails 18:39:25 do you get the stack size value differently? 18:39:29 as usual, all I can say is trace it and find it 18:39:37 * AnMaster sighs 18:39:38 I can't remember, probably f8+y or whatever 18:40:50 Deewiant, you are not testing that size of stack works as it should btw 18:40:57 it says one cell for each stack 18:41:04 just saw my code just push for the top stack 18:41:04 heh 18:41:40 huh? 18:41:47 oh, right 18:41:51 That the stack sizes are [ 57 ] from top to bottom 18:41:52 sure 18:41:58 should be [ 0 ] 18:41:58 (though not correct either) 18:42:01 indeed 18:46:36 Deewiant, what exactly does this one mean: 18:46:37 UNDEF: the empty string wrapped around the edge of space contains 1 character(s) (hopefully spaces) 18:47:32 Deewiant, btw I found a real bug in your code now 18:47:33 That the command-line arguments were: [ "mycology.b98" ] 18:47:34 That the environment variables are: 18:47:34 =/home/arvid/bashfunge/trunk/std08/interpreters/ccbi/ccbi_linux/ccbi_linux/ccbi 18:47:34 TERM=t 18:47:40 on env -i TERM=t 18:47:49 mine at least does the right thing on that :) 18:48:02 That the command-line arguments were: [ "/home/arvid/bashfunge/trunk/mycology/mycology.b98" ] 18:48:02 That the environment variables are: 18:48:02 TERM=t 18:48:13 Deewiant, any idea about that? 18:49:05 actually it does that in any case 18:49:11 That the command-line arguments were: [ "mycology.b98" ] 18:49:11 That the environment variables are: 18:49:11 =/home/arvid/bashfunge/trunk/std08/interpreters/ccbi/ccbi_linux/ccbi_linux/ccbi 18:49:15 and so on 18:49:42 doesn't do that with mi 18:49:44 err 18:49:45 me 18:49:58 env -i ccbi mycology.b98 18:50:01 That the environment variables are: 18:50:03 and nothing 18:50:27 yes 18:50:29 but try setting one 18:50:35 env -i TERM=t ccbi mycology.b98 18:50:38 like that 18:50:38 it goes through extern char **environ for the environment variables 18:50:40 see what you get 18:50:46 Deewiant, I use **environ too 18:51:20 AnMaster: I don't get that 18:51:22 only TERM=t 18:51:26 Deewiant, weird 18:51:28 very weird 18:51:38 env -i TERM=t ./ccbi mycology.b98 18:51:41 is the exact line I used 18:51:54 as it both are in current dir 18:52:22 using the exact same line, only TERM=t 18:52:35 hm? 18:52:59 env -i TERM=t ./ccbi mycology.b98 18:53:04 TERM=t, nothing else 18:53:25 Deewiant, the binary you sent me (the last that is, will check this for earlier ones) produces that "fake" env variable, even without anything else, then the rest of the variables 18:54:10 Deewiant, however mine produce another line your doesn't: 18:54:12 _=./cfunge08 18:54:14 with at _ there 18:54:23 maybe you mess up with space and _ ? 18:54:44 or wait you do that one too, just differently sorted 18:54:53 but mine doesn't do that empty variable name one 18:55:06 neither does mine, here :-P 18:55:17 Deewiant, your older ones does too 18:55:35 your machine is weird :-P 18:55:53 something is weird 18:57:45 -!- olsner has joined. 18:58:07 Deewiant, ok you are right, something is odd, I don't get it on my other amd64 18:58:18 nor do I in another xterm 18:58:21 wtf 18:58:23 :-D 18:58:30 that's crazy 18:59:54 actually I do get it in another xterm, in some 18:59:54 wtf 19:00:17 also I didn't get it before 19:01:35 Deewiant, found out about: BAD: : on empty stack doesn't make stack size 2, says y 19:01:42 Deewiant, reason is simple, very simple 19:01:45 I peek and then push 19:01:49 not pop and push twice 19:02:04 and my stack dumping had a off by one in one case 19:02:09 I thought you said gdb claims it has 2 :-P 19:02:12 hah 19:02:36 however, would this difference affect any program? 19:02:54 you will always get 0 from an empty stack 19:03:07 Deewiant, right? 19:03:32 the difference is what f8+y pushes :-) 19:03:42 it's the only way of measuring it :-P 19:03:43 so if you say do: n: you will always get the same result, for instructions except for what y says 19:04:10 so, does it matter really? peak and push is logically faster than pop and push 19:04:38 the spec says : is equivalent to pop and two pushes 19:04:43 it might matter to some fingerprints 19:04:52 so I'll do some #ifdef for FULLY conforming vs. some slight optimizations 19:04:55 :D 19:05:03 Deewiant, err how? 19:05:05 you're an optimization freak 19:05:09 AnMaster: I don't know 19:05:15 how would it matter 19:05:34 they use : to quickly get the stack size up to 2 for some freakish extension that they provide which cares about that :-P 19:05:45 err whatever 19:06:02 I don't know, like I said 19:06:06 but the spec says what it says 19:06:15 extensions still won't have access to the array I use for stack 19:06:26 so, doesn't matter 19:07:07 because it isn't a straight simple array, it's dynamically malloced in chunks, and keeps a size value and a top pointer. extends with 10 entries every time the array needs to grow, but doesn't actually ever contract 19:07:15 just moving top pointer downwards 19:07:26 yes, that's what I do as well 19:09:44 ah this should be faster unless stack actually is empty: 19:09:46 if (stack->top == 1) 19:09:46 StackPush(0, stack); 19:10:01 still not as good as just peek and push but 19:10:27 you optimize too much :-P 19:10:46 nah 19:11:22 I plan to make this the fastest befunge interpreter on 64-bit when I'm done, and with a changing some values in a header it should perform well on 32-bit too 19:12:03 it's already the fastest from the sound of it 19:12:26 heh, fastest with some fingerprints please :) 19:12:45 I may need to replace hash array if it turns out to be bad, but the way I coded it replacing is easy 19:12:53 it's all hidden under an abstraction 19:13:06 that's how you should code everything, goes without saying 19:13:14 yep 19:13:30 stack, ip and fungespace are all quite hidden under abstractions 19:14:09 Deewiant, http://rafb.net/p/Uk3wTE20.html 19:14:33 restrict :-P 19:14:43 yes because I had to beat you 19:14:47 :P 19:14:55 you optimize too much, like said 19:14:59 it really doesn't matter :-P 19:15:04 Deewiant, not really, look at memcpy 19:15:09 it uses restrict 19:15:34 yes, I am well aware of the fact that the STANDARD LIBRARY has to be well optimized 19:15:43 but your program doesn't have to be fully micro-optimized :-P 19:22:15 -!- sebbu has joined. 19:24:42 o/ 19:25:35 Deewiant, hehehe :D 19:26:50 AnMaster: where do I get libcord 19:27:18 doesn't come with latest stable boehm-gc 19:28:01 Deewiant, uh? 7.x? 19:28:16 AnMaster: latest stable in portage is 6.8 19:28:45 Deewiant, yes I know, I think it is a mistake by portage in some way, because even for 6.8 it installs the *header files* for cord 19:28:48 just not the library 19:28:57 a bit confusing that 19:29:43 Deewiant, I'm well aware of that my cmake checks are incomplete, and I plan to extend them 19:29:44 I thought you said you don't run unstable packages :-P 19:29:57 Deewiant, I avoid them mostly 19:30:02 this is a special case though 19:30:18 I already had to get unstable bzr as well :-P 19:30:34 Deewiant, oh? yes I don't think there is a stable bzr in portage is there? 19:30:43 not a 1.x one at least 19:30:45 sure, 0.17 :-) 19:30:53 Deewiant, that is so old and crappy 19:31:16 Deewiant, 1.0 was released several months ago, like November or something like that 19:31:28 0.17, about a year ago at least I guess 19:31:31 not 100% sure 19:31:47 Deewiant, anyway you could have used 0.92 :P 19:31:56 (why you would want that I don't know) 19:31:58 AnMaster: 0.17 and 1.1 are the only two in portage 19:32:06 Deewiant, 1.1 is great 19:32:18 AnMaster: on my machine, CCBI is faster than cfunge08 in bzr 19:32:28 does cmake build with optimization? 19:32:35 Deewiant, two things 19:32:39 ccmake 19:32:47 change build type to RELEASE 19:32:55 that will get optimzing 19:33:01 the second (if on 32-bit) 19:33:01 how 19:33:07 Deewiant, how what? 19:33:12 do I change it to RELEASE 19:33:19 ccmake . 19:33:28 use arrow keys to select CMAKE_BUILD_TYPE 19:33:32 pres enter to edit option 19:33:33 bah, GUIs... 19:33:38 make sure it says RELEASE 19:33:49 Deewiant, you can do it with cmake, but I don't remember how! 19:34:04 ccmake is ncurses anyway 19:34:28 Deewiant, ok, second thing (if on 32-bit), open src/global.h 19:34:43 aye, fast32_t 19:34:55 and change FUNGEDATATYPE and FUNGEVECTORTYPE indeed 19:35:25 alright, now we're talking 19:35:31 Deewiant, better speed now? 19:35:39 still got some issues with y 19:35:42 working on those 19:35:56 0.08 for cfunge08, 0.13 for CCBI 19:36:09 you get better speed than I do, for both of them 19:36:11 hehehe 19:36:39 -!- RedDak has quit (Read error: 110 (Connection timed out)). 19:36:51 with output, 0.10 and 0.14 19:36:56 -!- Dagide has joined. 19:36:58 i.e. not piped to devnull 19:37:30 I can accept being 50% slower for using a language which is much more fun to code in :-) 19:37:45 + for supporting all kinds of crap that cfunge08 doesn't ;-) 19:37:53 hehe 19:38:01 Deewiant, I will add fingerprints 19:38:13 and those may be slower 19:38:19 but the core should be faster :D 19:38:22 AnMaster: I get some warnings from compiling your code, mostly stuff like %ld being used to print 19:38:38 Deewiant, ah, that's related to you changing FUNGEVECTORTYPE 19:38:40 and such 19:38:49 AnMaster: no, I got it even without changing them 19:38:49 -!- Corun has quit ("This computer has gone to sleep"). 19:39:09 AnMaster: warning: format '%ld' expects type 'long int', but argument has type 'int_fast64_t' 19:39:16 AnMaster: or int_fast32_t, both result in warnings 19:39:26 AnMaster: you should use inttypes.h 19:39:28 Deewiant, err right, on x86 that should be long long gah 19:39:34 Deewiant, I use stdint! 19:39:40 it's more C 19:39:43 iirc 19:39:50 AnMaster: no, you should use inttypes.h instead of %ld I mean 19:40:03 AnMaster: inttypes.h has corresponding printf/scanf specifiers for stdint.h's integer types 19:40:07 AnMaster: both are C99 19:40:35 aha 19:40:37 what you want is PRIdFAST64 instead of '%ld' 19:40:44 and PRIdFAST32 for fast32_t 19:40:45 I see forgot that 19:40:45 I think 19:40:54 or didn't know ;-) 19:40:57 Deewiant, well fast32_t is not really supported 19:41:06 alright, then 64, whatever 19:41:13 anything but hardcoded '%ld' :-) 19:41:14 Deewiant, how slow was it with 64-bit btw? 19:41:23 Deewiant, I agree I should fix that indeed 19:41:27 AnMaster: 0.38, without optimizations and with 64-bit 19:41:35 AnMaster: so about 2.5 times slower than CCBI 19:41:36 interesting 19:41:42 or more like 3 times 19:41:43 actually 19:41:48 since 0.39 would be 3 times 19:41:50 Deewiant, about as fast as it gets on my cpu when mine is at it's best 19:41:56 :-) 19:41:59 :/ 19:42:05 your cpu is faster it seems 19:42:05 AnMaster: also, there are other warnings 19:42:16 Deewiant, I'm aware of some yes 19:42:16 yeah, my laptop's cpu is faster than my main computer's :-) 19:42:24 /home/arvid/src/cfunge08/src/interpreter.c:422: warning: function might be possible candidate for attribute 'noreturn' 19:42:25 stuff like that 19:42:33 hash library got a few too 19:42:42 AnMaster: comparison between signed and unsigned, cast discards qualifiers, unused params 19:42:46 but it's third party and I haven't had time to look at it' code 19:43:04 I had a fun idea for an esoteric programming langue. 19:43:05 AnMaster: support.c:118 has 'signed and unsigned type in conditional expression' 19:43:07 language 19:43:20 Deewiant, I know about those yes, lib/*, the "noreturn", the one in support.c (it's a function from gnulib!) 19:43:33 Deewiant, because getline isn't portable I used the gnulib one always 19:43:35 AnMaster: alright 19:43:38 heh 19:43:47 and means boehm-gc too 19:43:56 Deformative, tell us! 19:44:20 Continuation based, no return values. 19:44:22 Functional. 19:44:41 ew, no return values 19:44:47 I will explain more later, I kinda wanna take a nap, 19:44:59 Deformative, interesting 19:45:11 Deewiant, oh and I found a bug in gdb today 19:45:12 :) 19:45:17 I managed to do the factorial sequence. 19:45:23 it can't print the extern **environ 19:45:28 it just shows 0x0 for it 19:45:31 for unknown reason 19:46:08 I don't use debuggers so I can't help you with that 19:46:34 AnMaster: It is quite a bit of fun. 19:46:55 Should theororetically be far faster too. 19:47:11 Deformative: I want to see a spec 19:47:12 Deewiant, how do you fix bugs then? 19:47:13 Forth might be faster. 19:47:25 AnMaster: I find them and I fix them as normal. :-P 19:47:51 I will make up a spec in the next few days maybe. 19:47:52 AnMaster: to find them - CCBI has its debugging mode which I found really handy 19:48:01 AnMaster: if that wasn't enough, liberal printf sprinkling in the code helps 19:48:05 Maybe publish it. 19:48:48 Deewiant, heh 19:48:55 It is really weird at first, but the more you use it, it gets easier. 19:49:02 And knowing forth helps a lot. 19:51:22 I really should learn some factor 19:51:28 Nah,. 19:51:34 Factor is nothing, learn forth. 19:51:36 Forth is real. 19:51:41 heh 19:51:52 well, to be honest, any concatenative language would be fine 19:52:06 Forth, the origional. 19:52:31 on my first try with Forth I got lost somewhere around loops and recursion 19:52:41 and the alternative stack 19:53:06 need to try again at some point 19:53:10 Ah. 19:53:17 I don't remember forth that much. 19:53:22 :-D 19:53:22 But I did finish the book, I remember that much. 19:53:55 Joy is nice too, I hear 19:54:06 Yeah. 19:54:11 But again. 19:54:13 It is nothing. 19:54:19 :-) 19:54:20 and the alternative stack 19:54:26 well after befunge that's NOTHING 19:54:26 :P 19:54:39 * AnMaster still thinks his stack stack code is uggly 19:54:41 except that befunge isn't supposed to be easy 19:54:45 Forth has some real implementations and there has been real programs made in it. 19:54:47 forth is :-P 19:54:52 Factor and joy have nothing, 19:55:09 Forth is rather beautiful. 19:55:41 A colored stack language has real potential, but I don't think that moore did it right with colorforth. 19:56:01 Deewiant, also if I ever implement = it will be in some unusual way, maybe running the string "under a specific shell or interpreter" as in befunge XD 19:56:09 or doing libffi to call C functions with it 19:56:54 Deformative, colored stack!? 19:56:57 wtf is that 19:57:04 (Yay libffi) 19:57:15 AnMaster: Color as part of the syntax 19:57:32 Red does one thing blue another. 19:57:51 Deformative, err, then you load it as an image? 19:57:57 No. 19:58:00 how then? 19:58:16 latex code using colors? 19:58:28 The editor puts apropriat char in plazced.' 19:58:40 Wow, soprry trying to type with one hand. 19:58:42 you mean ANSI escape codes? 19:58:45 Cheetos. 19:58:55 It can be implemented like that. 19:58:59 I do not know how colorforth does it. 19:59:04 that's messy :/ 19:59:17 program source should work in mono color 19:59:22 Colorforth is the only colored language that I know of. 19:59:24 as in black and white 19:59:28 I am sure there are more. 19:59:38 I like it because it results in less characters. 19:59:42 Less characters = better 19:59:49 but there are downsides too 19:59:52 Easy to read too. 19:59:58 Unless you are colorblind. 20:00:00 like impossible to syntax highlight automatically 20:00:15 Why would you need syntax highlighting? 20:00:20 Deformative, impossible for color blind, won't work on non-color terminals, and several more 20:00:48 You can make an editor put some char in place of the color. 20:02:05 Deewiant, also would need a special editor 20:02:13 wouldn't work in your standard editor 20:02:22 vim/emacs/kate/kdevelop/whatever 20:02:45 Some color can be evaluate, another push to stack, another comment, and maybe another can be for labels or conditional compilation. 20:05:27 Deewiant, how do you make ccbi print instructions as it executes them 20:06:01 because I found an obscure program a friend made that works in ccbi but not in cfunge 20:06:10 http://rafb.net/p/642T6v69.html 20:13:18 AnMaster: it has nothing like that, only the debug mode 20:13:40 :( 20:14:02 the debug mode is better, just use that 20:15:16 Deewiant, I can't set several breakpoints!?? 20:15:31 AnMaster: one global one and one for the current IP, so 2 at most 20:16:07 * AnMaster ponders writing some interface in his for attaching an external debugger 20:16:18 -!- ais523_non-admin has joined. 20:16:25 AnMaster: and then the 'cbreak' which breaks the next time it hits a given char 20:16:41 which is global 20:16:46 err 20:16:53 cbreak 20:16:53 Enter cell value to break on: j 20:16:53 'j' is invalid. 20:17:01 did I misunderstand you? 20:17:02 j isn't a value 20:17:03 you need a number 20:17:19 sorry, I was too lazy to implement ASCII translation 20:17:19 oh it can't convert can it, right 20:17:30 because you do need to support arbitrary values 20:17:42 Undefined command 'cbreak j'. See 'help'. 20:17:44 * AnMaster sighs 20:17:48 :-) 20:17:58 Breaking on every cell with value 106 (0x6a), character 'j'. 20:17:59 lol 20:18:02 the other way you did 20:18:08 well because that's trivial 20:18:10 that's just cast(char) 20:18:48 * ais523_non-admin is worried that they can translate 0x6a to 'j' in their head 20:19:10 ais523_non-admin: what's with the non-adminness 20:19:24 Deewiant: it's my Wikipedia alternate account 20:19:30 for use when I'm at a public computer 20:19:37 ah 20:19:37 which I don't want to know any of my super-secure passwords 20:19:48 I'd pick a shorter nick :-) 20:19:53 this is an unregistered nick 20:20:07 and I'm using it because I don't want to teach this client my Freenode password 20:20:33 it's still long 20:20:44 the reason I'm using this account, incidentally, is to use some Windows software (under Wine, as it happens) 20:21:13 I install software under Wine in separate accounts, because I don't trust trial-period software to not mess up my system 20:21:22 but running on a non-root non-wheel account, it's hard to see what could happen 20:21:48 I can always just wipe out the account and start afresh, and the software has no memory of previous trial periods 20:22:12 (the ironic thing is that the software is GPL anyway, so I just looked at the code, saw how the trial-period check was implemented, and added a workaround) 20:22:25 WTF? 20:22:27 (shareware GPL was an ingenious idea but doesn't survive contact with people like me) 20:22:41 (and the GPL means it's legal to remove the trial-period restruction) 20:22:43 That makes less than zero sense. 20:22:46 s/restruction/restriction/ 20:22:57 it's a compiler for an embedded system that's based on gcc 20:23:30 the people who wrote it distribute a shareware precompiled version in the knowledge that most of their customers won't even try to recompile it to remove the shareware restriction, and will pay them instead 20:23:30 I admire the effort, but that's just sort of silly :P 20:24:07 Deewiant, actually that program I posted shows a tricky corner case related to jumping backwards with j and wrapping at the same time 20:24:08 :/ 20:24:10 I think that's the way it should be done - you open your source and thus are a good guy, but you still get money from 90% of your clients 20:24:11 If this was the customers of a game, maybe, but I have to imagine that most programmers can figure out how to compile GCC ... 20:24:17 Deewiant, may be interesting to test in mycology 20:24:17 I tried to recompile it but couldn't, so I'm in the silly situation of running a GPL version of gcc under wine 20:24:23 (I can recompile gcc, just not their version) 20:24:39 AnMaster: it tests wrapping with # and x, I can't expect that you do j differently :-P 20:24:57 Deewiant, hah 20:27:20 AnMaster: for j, just save the delta, call x, move once, and reset the delta ;-) 20:27:40 Deewiant, hmm, less elegant (and less performant :/) 20:27:46 but I guess you are right 20:28:04 I'd argue it's more elegant, because that's essentially what x is 20:28:07 er, what j is 20:28:19 it's the simplest solution 20:28:54 -!- Dagide has quit (Remote closed the connection). 20:28:56 hrrm 20:28:57 given that you have a working x of course :-P 20:29:39 yes i do 20:29:52 are you /sure/? ;-) 20:29:59 -!- Judofyr has joined. 20:30:00 Deewiant, the problem is how it wraps based on delta rather than jumps in j case 20:30:02 one thing mycology doesn't test is wrapping both edges at once 20:30:04 and hard to avoid that 20:30:13 Deewiant, hm you mean double wrap? 20:30:22 AnMaster: I mean wrap x and y at the same time 20:30:25 ah 20:30:37 it doesn't test wrapping x twice in one instruction either does it? 20:30:45 no, probably not 20:30:45 as in a VERRRY long jump 20:31:17 Deewiant, until you test those I'm fine, though wrapping x and y should work as my current copying code for non-cardinal is same as yours basically 20:31:22 same algorithm 20:31:31 err wrapping not copying 20:31:34 * AnMaster is tired 20:31:34 and mine is just verbatim what the spec says :-P 20:31:59 Deewiant: it isn't possible to wrap twice round one coordinate in one instruction in Funge-98, due to the nature of Lahey-space 20:32:04 Deewiant, so if your fails at x and y at the same time, you got to fix your twice 20:32:11 ais523_non-admin, err? 20:32:13 at least, that's how I understand it 20:32:17 ais523_non-admin: well, depends on how you think about it really 20:32:39 if you would jump out of bounds, instead you don't and go backwards until you would go out of bounds, then go forwards again 20:32:55 so if the delta is larger than the playfield width, you just get stuck at the same point for all eternity 20:33:06 hrm 20:33:32 hmm, with x that's probably right 20:34:03 of course, with j you can wrap round more than once 20:34:13 because the delta is small, but the number of steps is large 20:34:15 yes with j it's an issue 20:34:29 implementing j as I said above still works, though 20:34:38 Deewiant, anyway I copied both your wrapping code and your j code now and I still don't get it right 20:34:40 the wrap doesn't change your position and then you just move as normal 20:34:41 wtf 20:34:43 :-P 20:35:11 oh wait 20:35:21 you actually move with a while loop :( 20:35:27 that's ineffective 20:35:37 ? 20:35:42 while (n--) 20:35:42 ip.move(); 20:35:46 your j code 20:35:48 in j, yes 20:35:56 doing what I said above would be faster :-) 20:36:01 hm true 20:36:18 but I'm not sure if it's the same 20:36:34 Deewiant, but I need to calculate how the delta should look like with j then 20:36:38 The j "Jump Forward" instruction pops a value off the stack, and jumps over that many spaces. 20:36:49 wait it is current delta times jump in each dimension right? 20:37:04 hmm, no, that is right, nevermind 20:37:14 Deewiant, oh? it should only work on space instructions? :P 20:37:29 AnMaster: "e.g. 2j789. would print 9 and leave an empty stack. " 20:37:31 AnMaster: so no. :-) 20:37:49 you could interpreter that sentence as it should only jump over spaces but not other instructions 20:37:50 ;) 20:38:03 hence the example which clarifies it 20:38:07 yeah 20:38:07 :/ 20:38:36 -!- timotiis_ has joined. 20:38:53 Deewiant, you won't need to same delta even I think 20:38:56 not sure yet 20:39:01 s/same/save/ 20:39:03 but you would get new delta with: 20:39:07 and yes, you do, if that's what you do 20:39:12 ip->delta.y *= jumps; 20:39:12 ip->delta.x *= jumps; 20:39:13 right? 20:39:21 then you could get old again using / 20:39:23 :D 20:39:29 (probably slower though) 20:39:32 well, sure, but the / slows it down :-P 20:39:33 AnMaster: as long as there wasn't integer overflow 20:39:42 hah true 20:39:42 and that 20:39:54 bloody corner cases :-P 20:40:22 hmm, this is the culmination of beautiful code 20:40:24 void noOperation() {} 20:40:38 hm if I run a program more than once / second I get same randomness 20:40:47 I guess time() isn't a good idea ;/ 20:40:52 as srandom 20:40:53 I mean 20:41:06 guess not 20:41:16 mersenne twister for teh win \o 20:41:21 hmm, this is the culmination of beautiful code 20:41:21 void noOperation() {} 20:41:22 hahaha 20:41:31 you know, some languages complains about such 20:41:33 bash is one 20:41:39 screw bash, then 20:41:43 it syntax errors on an empty function 20:42:00 mersenne twister for teh win \o <-- hm, does libc have that? 20:42:09 no, probably not 20:42:25 screw mersenne twister, then 20:42:30 (whatever it is) 20:42:32 heh 20:42:40 wtf is a "mersenne twister" 20:43:03 just google it 20:50:06 -!- timotiis has quit (Read error: 113 (No route to host)). 20:51:19 AnMaster: it's a randomisation technique 20:51:24 pseudo-randomisation, that is 20:52:01 you'll probably get enough randomisation by using a few bytes from /dev/random as a seed (if on a POSIXish system) 20:52:11 with the nice properties of being really fast, really random, and having a huge period 20:53:01 srandom(tv.tv_sec % tv.tv_usec); 20:53:03 what about that one 20:53:05 is it a good idea 20:53:06 ? 20:53:16 at least it gives different results each time now 20:53:24 anyone suggest a better way for srandom? 20:53:29 why not just usec directly 20:53:33 AnMaster: adding is likely better than taking the modulus 20:53:45 or using usec directly will perform much the same 20:54:02 (note that x % 0 = SIGFPE on many systems) 20:54:11 ais523_non-admin, ok, however if you run them exactly one second after each other you get issues 20:54:24 AnMaster: is anyone that accurate? 20:54:35 ais523_non-admin, probably not when multi tasking 20:54:35 AnMaster: why is it an 'issue' that two different calls can result in the same randoms? 20:54:50 AnMaster: since you're going posix anyway, just read from /dev/random like he said :-) 20:54:55 Deewiant, hm 20:55:09 cryptographically secure random seed right there 20:55:14 Deewiant, hm true 20:55:20 note: only read a few bytes from it so as not to run the system out of entropy, and use them as a seed 20:55:22 but very short supply of it 20:55:28 ais523_non-admin, yes exactly 20:55:36 4 bytes? 20:55:41 would that be enough 20:55:41 whatever srandom takes 20:55:46 sure 20:55:56 Deewiant, unsigned int 20:56:01 depends on platform then 20:56:11 so then read sizeof(unsigned) 20:56:13 on both x86 and x86_64 it would be 4 bytes 20:56:26 Deewiant, but it will slow me down on mycology :( 20:56:31 opening a stream I mean 20:57:13 AnMaster: on every initialization, CCBI populates the function pointer arrays for all instructions and fingerprints 20:57:14 AnMaster: you could just use open() and read() to save on stdio overhead 20:57:25 ais523_non-admin, that is true 20:57:33 Deewiant, hahaha 20:57:35 AnMaster: in addition, it initializes the randomizer by finding the current clock time, and other things 20:57:40 Deewiant, don't you have static arrays? 20:57:43 AnMaster: so I wouldn't worry 20:58:06 AnMaster: yes, I do, but I haven't bothered to do it like that 20:58:24 * AnMaster prefers his switch case 20:58:26 this way, the fingerprints can be removed simply by not compiling it in 20:58:31 you don't have to modify any code 20:58:39 just not pass the corresponding .d file on the command line 20:58:58 Deewiant: weak linking? 20:58:58 Deewiant, true, I plan to do fingerprints using some array indeed 20:59:08 ais523_non-admin: module constructors 21:00:47 Deewiant, anyway I got some ideas for optimizing this app even further, they are: 1) avoid using -fpic -fpie -pie that cmake adds for some reason (means non PIE binary, not as good for hardened but slightly faster), 2) use -combine -fwhole-program 21:00:49 :D 21:01:01 no idea if there will be a noticeable change 21:01:04 well, sure, using better optimization flags will speed stuff up 21:01:07 of course profiling info too 21:01:08 profile-guided optimization as well 21:01:11 and whatever 21:01:22 Deewiant, can't you do profiling with ccbi? 21:01:27 err D I mean 21:01:30 sure 21:01:47 nothing automated in the compiler for optimizing based on the resulting info, though 21:01:53 except maybe GDC, I don't know 21:02:11 like said, I can look at the results and just see that something is called 300 000 times and it takes 1 microsecond each time 21:02:15 can't optimize that much 21:02:32 gcc uses profiling data for branch predicition IIRC 21:02:56 so it works out which branch of an if is more likely to be taken, because not jumping is normally faster than jumping on a conditional jump instruction 21:03:29 gcc uses profiling data for branch predicition IIRC 21:03:30 indeed 21:03:34 that's what I'm doing 21:03:42 when speed testing against ccbi 21:03:49 it might depend on the program you're running as a test 21:04:00 and it does 21:04:02 ais523_non-admin, I use same that I speed test on 21:04:03 :D 21:04:08 so in fact, you could have an optimised-for-Mycology conforming Funge-98 interp, for instance 21:04:12 so you get a program that's ultra-tuned for Mycology 21:04:15 ais523_non-admin, exactly 21:04:16 but sucks for everything else :-P 21:04:24 Deewiant, yes right :D 21:04:42 but well I can ultra-tune it for anything 21:04:50 just rerun with profiling 21:04:52 to get that 21:05:03 well sure, but the idea is to have a well-rounded program for running Befunge scripts, not one which is really fast on one specific one :-P 21:05:20 Deewiant, then don't compile it with profiling info 21:05:25 just normal -O 21:05:32 you get something average 21:05:34 actually, any profiling info is likely to be better than no profiling info IMO 21:05:38 AnMaster: exactly, that's what I'm telling you ;-) 21:05:40 ais523_non-admin, oh? 21:05:46 ais523_non-admin: you're probably right 21:05:48 because some of your interp will be program-independent 21:05:54 ais523_non-admin: but don't tell him that! ;-) 21:05:55 ais523_non-admin, indeed 21:06:00 that's true 21:06:04 anyway the source is GPL3 21:06:14 you can compile it with any flags you want 21:06:19 it's your choice 21:06:29 I don't make binaries for downloads for any program I write normally 21:06:50 or you could do branch prediction by hand if you're using gcc; there's some compiler-specific thing (can't remember if it's a __builtin_ or a __attribute__) that lets you specify which branch you think is more likely 21:07:01 ais523_non-admin, yes I know about that 21:07:03 AnMaster: neither do I 21:07:17 even the Windows version of C-INTERCAL comes only in source form 21:07:30 but info page notes that "programmers are notoriously bad at guessing how their programs will perform" 21:07:33 so :P 21:07:46 I maintain a separate autoconf script for it and two separate shell scripts for if you can't get make to work 21:07:52 (one is written for bash, the other for cmd.exe) 21:08:06 the main autoconf script is for the POSIX build 21:08:13 ais523_non-admin, only place it is useful would be in, say, a library where you first has profiled for common usage, then you build that into the library source on "hotspots" 21:08:19 I think boehm-gc does that 21:09:09 and there is both a attribute (for hot/cold functions) in gcc 4.2 and later, and even in earlier a __builtin__ for branch prediction 21:09:56 ais523_non-admin, what irritates me is that it seems impossible to combine profiling info from several different runs :( 21:10:13 it overwrites instead 21:11:07 Deewiant, anyway even with -ggdb -O0 my interpreter is slightly faster than your with -O 21:11:26 D isn't good for speed is it? 21:11:29 ;P 21:11:30 AnMaster: yes, highly-optimized C beats lowly-optimized D. 21:11:36 this is not news. :-P 21:11:40 * ais523_non-admin was under the impression that -g doesn't slow down a program, only inflates its size 21:11:44 D is good for speed, if it's highly optimized. 21:11:48 Deewiant, yep indeed, however I do think D (partly) got a nice syntax 21:11:55 not fully however 21:12:08 of course, given the same degree of optimization, C will be faster 21:12:09 ais523_non-admin, yes but -O0 slows things down 21:12:15 yes 21:12:16 but the D will take 10% less time to write ;-) 21:12:28 ais523_non-admin, and also technically loading the larger program will be slower 21:12:38 if it's only 10% better I'll stick to C for that sort of thing 21:12:40 Deewiant, hum, I started at sunday and got this far 21:13:03 AnMaster: you've been working on it 24/7 judging from your posting here :-D 21:13:10 Deewiant, a lie 21:13:16 besides, I'm writing embedded system code at the moment, where C is too high-level for some things and so I've had to resort to assembler 21:13:17 Deewiant, I could have coded one in C# in about 1/3 of the time 21:13:24 it would have been LOADS slower 21:13:27 and larger 21:13:31 yep 21:13:43 you could have done the same in D, and it wouldn't have been that much slower or larger ;-) 21:13:45 AnMaster: and nonportable 21:13:54 ais523_non-admin, I'd use mono not .NET 21:14:03 so not as non-portable as it could be 21:14:07 but not very portable still 21:14:24 I'd argue .NET is more portable than Posix-only C :-P 21:14:51 Deewiant: most modern OSs are better at POSIX-C than at .NET 21:14:57 Deewiant, no because mono doesn't work on all POSIX 21:15:05 and I even have a sort-of-POSIX implementation for DOS 21:15:06 and even windows can do some POSIX I bet 21:15:18 AnMaster: Windows is actually POSIX-certified 21:15:19 given the number of machines that use Windows, Windows-only code is arguably more portable than anything else ;-) 21:15:27 ais523_non-admin, it doesn't have fork iirc? 21:15:27 yes, and Linux isn't :-) 21:15:32 but you have to download all sorts of weird expansions from Microsoft to get the full effect 21:15:42 ais523_non-admin, I see 21:16:03 * ais523_non-admin likes the definition of fork() on DJGPP (my POSIX-like compiler/environment for DOS) 21:16:20 it amounts to pid_t fork() {errno=ENOMEM; return -1;} 21:17:10 Deewiant, if you want a cfunge with a fixed j wrapping, run bzr pull 21:17:27 ais523_non-admin, -_- 21:17:37 ais523_non-admin, then no program will be able to run another one 21:17:50 ais523_non-admin, wait a second, you made DJGPP!? 21:17:53 wow 21:18:27 I'll always been thinking that DJGPP = cygwin gone insane 21:19:30 DJGPP predates cygwin, no? 21:19:38 maybe it does 21:19:40 or is cygwin older than I think 21:19:45 but did ais523_non-admin actually make it? 21:20:53 I doubt it, if he's alex smith 21:20:53 AnMaster: no I didn't 21:20:59 AnMaster: what did you imply that from? 21:21:22 AnMaster: it does handle system() and exec() OK 21:21:40 ais523_non-admin, err exec would replace current process 21:21:46 and system would lock it up 21:21:54 oh, I see, I was loose in my wording. I meant I used a copy often, not that I wrote it in the first place 21:22:05 aha 21:22:11 I had a tendency to get sh-sick when using Windows... 21:22:53 and DJGPP is a maintained target for C-INTERCAL, so that it runs on DOS and Windows too 21:23:06 ais523_non-admin, anyway the normal way on *nix for many programs is doing something like: vfork() if (return code from vfork whatever) { exec(whatever); } 21:23:11 and trapping SIGCHILD 21:23:17 AnMaster: I know 21:23:29 those would not work under DJGPP 21:23:31 BTW, what's the difference between fork and vfork? 21:23:47 ais523_non-admin, see man pages, but on linux, basically none iirc 21:23:54 it may matter on some *nix 21:24:05 where vfork is faster 21:24:16 -!- oerjan has joined. 21:24:16 as it suspends parent until it has run exec 21:24:44 ais523_non-admin, linux got "copy on write" pages or something like that for all forks however 21:24:57 yes, which is why Windows is DOG SLOW for forking 21:25:04 ais523_non-admin, vfork and setjmp are some of the few instructions that can return twice :) 21:25:04 and multiple processes in general 21:25:29 ridiculous that not even vista got the smart process model 21:25:36 Deewiant, heh 21:25:45 $ ps aux | wc -l 21:25:46 156 21:25:50 my linux runs fine 21:26:08 and I remember it was such a issue they merged several system services in xp into a single process 21:26:12 with different threads 21:26:14 heheh 21:26:42 Deewiant, windows wouldn't handle 156 processes would it? 21:26:43 yes, it's ridiculous 21:26:45 AnMaster: I have 119 by that ps count 21:26:51 sure it could handle a billion processes 21:27:11 creating a process just takes a second or two 21:27:11 whereas on linux, it's more like a millisecond or two 21:27:11 the only one that actually slows things down really, is virtual box when I run it 21:27:40 mostly when I run windows under virtualbox 21:27:52 for some reason linux and *bsd are nicer to the system 21:30:06 Deewiant, weird isn't it? 21:30:22 ? 21:30:30 ais523_non-admin, oh btw, I got everything between 78 and 156, depending on what user I run it under 21:30:41 information hiding++ 21:30:42 :) 21:31:13 $ ps aux | wc -l 21:31:14 4 21:31:16 su - 21:31:20 $ ps aux | wc -l 21:31:20 182 21:31:28 * AnMaster nods, on his freebsd server 21:32:05 but I thought the a meant it was irrelevant which user you were 21:32:25 or is it that on freebsd some users don't have permissions to determine the existence of other users' processes? 21:32:56 hmm... how come that su - didn't change your shell to # anyway? 21:44:18 -!- slereah_ has quit (Read error: 104 (Connection reset by peer)). 21:44:39 -!- slereah_ has joined. 21:57:41 -!- slereah__ has joined. 21:57:45 -!- slereah_ has quit (Read error: 104 (Connection reset by peer)). 21:59:53 or is it that on freebsd some users don't have permissions to determine the existence of other users' processes? 21:59:54 indeed 21:59:57 with the right sysctl 22:00:01 ais523_non-admin, as for $ and # 22:00:06 it depends on the PS1 I set 22:00:09 in my .bashrc 22:00:13 I change other things instead :) 22:01:04 ais523_non-admin, and you can do that on linux with some hardening kernel patchsets 22:01:38 ais523_non-admin, and with the sysctl set on freebsd you can only see your own processes unless you are root 22:05:22 ais523_non-admin, the 4 on freebsd as a user were: ssh, bash, ps and wc 22:05:23 :) 22:07:26 hmm... I wonder if it's possible to use ps as an esolang, by starting and ending processes according to what it outputs? 22:08:07 However, that would just be using ps as a data store, unless each of the processes that was created as a result itself did something or other interesting, which would make for an interesting language where each datum is also a thread that does things 22:22:12 -!- slereah__ has quit (Read error: 110 (Connection timed out)). 22:28:26 -!- slereah__ has joined. 22:33:42 -!- slereah_ has joined. 22:34:03 -!- slereah__ has quit (Read error: 104 (Connection reset by peer)). 22:44:26 ais523_non-admin, huh? 22:45:10 basically you would have processes that communicated by starting other processes (of much the same nature as themselves) and reading ps to see what data was available 22:45:20 it would be horrendously inefficient and tricky to program, of course 22:45:55 ais523_non-admin, and, also concurrency issues 22:46:14 even on single cpu 22:46:24 programs could end before they got read and so on 22:46:40 that would just make programming it all the more interesting 22:46:51 it wouldn't work 22:47:10 not unless threads sleep for quite some time 22:47:18 but sure, go ahead and design it 22:47:27 there must be worse esoteric languages out there 22:48:18 -!- RedDak has joined. 22:59:26 -!- RedDak has quit (Remote closed the connection). 23:02:53 -!- jix has quit ("CommandQ").