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