00:05:57 -!- BMeph has joined.
00:07:30 -!- RodgerTheGreat has joined.
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:09:40 <RodgerTheGreat> if (abs(vx) > abs(vy)) {max = vx;} else if (vy != 0) {max = vy;}
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:12:07 <oerjan> you're using the max (L^infinity) norm...
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: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: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: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: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: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: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: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: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: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: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: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: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: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: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.
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.
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: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 <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: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:32 <Deewiant> they worked on cygwin, I think
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:59 <Deewiant> I just copied RC/Funge's implementation
12:49:11 <AnMaster> curses will use terminfo databse
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: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:58 <oerjan> terminfo is an improved system on termcap iirc
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:51 <Deewiant> AnMaster: you haven't run that one
12:52:52 <Deewiant> hmm, I can't use curses, right
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:19 <Deewiant> because TERM doesn't have any "initialize" instruction, but NCRS does
12:56:15 <AnMaster> but it doesn't clear the screen at the start or such
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:59:49 <AnMaster> /usr/include/ncursesw/term.h ?
13:00:38 <AnMaster> $ diff /usr/include/term.h /usr/include/ncursesw/term.h
13:00:38 <AnMaster> > #include <ncursesw/ncurses_dll.h>
13:01:28 <AnMaster> Deewiant, btw can a fingerprint be loaded several times?
13:01:40 <AnMaster> say 1) load fingerprint 2) load some other 3) load it again
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:17 <AnMaster> Deewiant, it probably shouldn't
13:03:11 <Deewiant> so what should one do after endwin()?
13:03:32 <Deewiant> AnMaster: since initscr() is only called when the instruction I is called
13:03:38 <Deewiant> nothing happens when loading NCRS
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:06:27 <AnMaster> weird, now pasting started working in irc client again
13:06:44 <AnMaster> Deewiant, btw, does D use a garbage collector?
13:07:30 <AnMaster> not boehm then when using gdc?
13:07:44 <oklokok> Deewiant: what age are ya?
13:07:54 <AnMaster> considering boehm is used for the gcj thing iirg
13:08:21 <oklokok> Deewiant: math matriculation exams were just now, so i was just checking whether you happened to do that too
13:09:55 <oklokok> prolly not, programmers tend not to fail enough to be at high school at the age of 20
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> 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: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: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:18:15 <AnMaster> ok down with another 0.2 now, almost as fast as with static array for fungespace
13:19:24 <Deewiant> AnMaster: how do you do output, btw
13:20:03 <AnMaster> and I flush after each put char
13:20:18 <AnMaster> would make it faster to just flush at input or newline
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: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:57 <AnMaster> sounds like that think ais[0-9]+ (can't remember actual nick) talked about
13:22:39 <AnMaster> Deewiant, so I'm not going to implement TRDS then
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:45 <AnMaster> Deewiant, indeed, but I got a question
13:24:16 <AnMaster> you load "PRINT", then load NULL, then unload NULL
13:24:27 <AnMaster> should instructions now map to PRINT again
13:24:55 <AnMaster> so you need to keep some special instruction stack for each char to get loading right
13:25:19 <AnMaster> also, is it possible to do load PRNT, then QUUX then unload PRNT
13:25:35 <AnMaster> and what should happen in such cases
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:22 <Deewiant> then after that DE are bound to QUUX and ABC to PRNT
13:28:00 <Deewiant> go over it, draw a diagram or two if it helps
13:28:26 <AnMaster> 1) load PRNT 2) load QUUX 3) *UN*load PRNT
13:28:38 <AnMaster> you must have misunderstood what I meant?
13:28:43 <Deewiant> no, I believe I was quite correct
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:24 <Deewiant> ABCDE are bound to QUUX's funcs
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:50 <Deewiant> DE still have a stack of the form [PRNT, QUUX]
13:31:07 <Deewiant> because when unloading PRNT, you only popped from ABC.
13:31:13 <AnMaster> then the stack should end up as [<empty>, QUUX] possibly? and then getting compacted to be just [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: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:28 <Deewiant> so back at load QUUX: [PRNT, QUUX]
13:33:46 <Deewiant> and yes, that's what the spec says.
13:45:14 <AnMaster> Deewiant, but you can't unload a non-loaded fingerprint right?
13:45:43 <AnMaster> it should reflect then shouldn't it?
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: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:51 <AnMaster> I will research how tput does it
14:17:58 -!- timotiis has joined.
14:20:43 <AnMaster> Deewiant, if you want I'll wgetpaste tput's source
14:20:55 <AnMaster> http://rafb.net/p/v2UBD448.html
14:39:05 -!- whice has joined.
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:05 <AnMaster> BAD: 0y pushes wrong stack size
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: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:18 * AnMaster does pass fspace around a lot, but that could be fixed
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: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: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: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: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:24 <Deewiant> just check the spec yourself :-P
16:34:50 <AnMaster> That the time is 00 : 08 : 1128682830
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: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:48 <Deewiant> for the date it might have been
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:39:09 <Deewiant> you give it incorrect values and it produces incorrect output :-P
16:40:53 <Deewiant> looks like the code that calculates it
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
17:03:01 <AnMaster> That the environment variables are:
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: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:50 <AnMaster> just time and gmtime needed then
17:07:02 <Deewiant> there's a fingerprint which allows both UTC and local
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:25 <Deewiant> ./cfunge08 isn't supposed to be there btw
17:15:20 <AnMaster> That the command-line arguments were: [ null "./cfunge08" "/home/arvid/bashfunge/trunk/mycology/mycology.b98" null ]
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: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:17:17 <Deewiant> and I'm not going to figure out why
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:36 <AnMaster> because, both these are valid main() prototypes in C:
17:18:40 <AnMaster> int main(int argc, char *argv[])
17:18:49 <AnMaster> int main(int argc, char *argv[], char*envp[])
17:18:56 <AnMaster> not sure of name for the latter
17:19:11 <Deewiant> I don't know what it is but it's not standard C :-P
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: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:45 <AnMaster> well popping and pushing 0gnirts are harder then
17:21:15 <AnMaster> for (ssize_t i = len; i >= 0; i--)
17:22:02 <Deewiant> ip.stack.push(cast(cell)*s--);
17:22:13 <Deewiant> AnMaster: you're missing the calculation of len, which is a call to strlen
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:23:15 <AnMaster> Deewiant, and allows potential for cashing string length in case I push the same several times or such
17:23:32 <Deewiant> I only use pushStringz with fingerprints, though
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: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:42 <AnMaster> (/* Extensible cords are strings that may be destructively appended to. */
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:32 <AnMaster> Deewiant, cord isn't an abbrev
17:26:46 <AnMaster> cord and string are both think long objects :P
17:26:56 <Deewiant> just wondering why it's called cord and not just string
17:27:04 <Deewiant> since, after all, "cords are [...] strings" :-P
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:22 <AnMaster> typedef struct CORD_ec_struct {
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: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:35:10 <Deewiant> how about without fingerprints? :-)
17:35:33 <AnMaster> won't it fail then due to no popping?
17:36:26 <Deewiant> or ccbi --disable-fprints, same thing
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: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:41:03 <Deewiant> thing is that there's nothing obviously slow that I can find
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: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:43:06 <Deewiant> none of those extra-optimized k ones are called in mycology
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: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:21 <AnMaster> may mean some overhead but faster at load time
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:45:04 <AnMaster> Deewiant, no clue, read about PaX on wikipedia
17:45:37 <AnMaster> Deewiant, that is I call hash creation with initial size set to slightly more chars than is in mycology
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: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:34 <AnMaster> like __attribute__((warn_unused_result))
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: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: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: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: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: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: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: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: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:42 <AnMaster> void changemyparameter(char * foo);
17:57:48 <AnMaster> so it opterates on the thing in place
18:00:12 -!- jix has joined.
18:02:19 -!- jix has quit (Client Quit).
18:02:49 -!- jix has joined.
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: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:33 <AnMaster> and mycology fails to handle that
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:19 <Deewiant> and then you can have nulls in strings
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: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: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:51 <AnMaster> That the stack sizes are [ 57 ] from top to bottom
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: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: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:50:01 <Deewiant> That the environment variables are:
18:50:35 <AnMaster> env -i TERM=t ccbi mycology.b98
18:50:38 <Deewiant> it goes through extern char **environ for the environment variables
18:51:38 <AnMaster> env -i TERM=t ./ccbi mycology.b98
18:52:22 <Deewiant> using the exact same line, only TERM=t
18:52:59 <Deewiant> env -i TERM=t ./ccbi mycology.b98
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: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:17 <AnMaster> Deewiant, your older ones does too
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:59:54 <AnMaster> actually I do get it in another xterm, in some
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: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:36 <AnMaster> however, would this difference affect any program?
19:02:54 <AnMaster> you will always get 0 from an empty stack
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: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: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: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:09:44 <AnMaster> ah this should be faster unless stack actually is empty:
19:10:01 <AnMaster> still not as good as just peek and push but
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: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:55 <Deewiant> you optimize too much, like said
19:15:04 <AnMaster> Deewiant, not really, look at memcpy
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:26:50 <Deewiant> AnMaster: where do I get libcord
19:27:18 <Deewiant> doesn't come with latest stable boehm-gc
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: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: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: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: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:18 <Deewiant> AnMaster: on my machine, CCBI is faster than cfunge08 in bzr
19:32:28 <Deewiant> does cmake build with optimization?
19:33:28 <AnMaster> use arrow keys to select CMAKE_BUILD_TYPE
19:33:49 <AnMaster> Deewiant, you can do it with cmake, but I don't remember how!
19:34:28 <AnMaster> Deewiant, ok, second thing (if on 32-bit), open src/global.h
19:34:55 <AnMaster> and change FUNGEDATATYPE and FUNGEVECTORTYPE indeed
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:39 -!- RedDak has quit (Read error: 110 (Connection timed out)).
19:36:56 -!- Dagide has joined.
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:38:01 <AnMaster> Deewiant, I will add fingerprints
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: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: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:37 <Deewiant> what you want is PRIdFAST64 instead of '%ld'
19:40:57 <AnMaster> Deewiant, well fast32_t is not really supported
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:50 <AnMaster> Deewiant, about as fast as it gets on my cpu when mine is at it's best
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: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: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:44:47 <Deformative> I will explain more later, I kinda wanna take a nap,
19:45:11 <AnMaster> Deewiant, oh and I found a bug in gdb today
19:45:23 <AnMaster> it can't print the extern **environ
19:46:08 <Deewiant> I don't use debuggers so I can't help you with that
19:47:11 <Deewiant> Deformative: I want to see a spec
19:47:12 <AnMaster> Deewiant, how do you fix bugs then?
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:55 <Deformative> It is really weird at first, but the more you use it, it gets easier.
19:51:22 <Deewiant> I really should learn some factor
19:51:52 <Deewiant> well, to be honest, any concatenative language would be fine
19:52:31 <Deewiant> on my first try with Forth I got lost somewhere around loops and recursion
19:53:06 <Deewiant> need to try again at some point
19:53:22 <Deformative> But I did finish the book, I remember that much.
19:54:20 <AnMaster> <Deewiant> and the alternative stack
19:54:26 <AnMaster> well after befunge that's NOTHING
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: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:57:51 <AnMaster> Deformative, err, then you load it as an image?
19:58:28 <Deformative> The editor puts apropriat char in plazced.'
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:38 <Deformative> I like it because it results in less characters.
20:00:00 <AnMaster> like impossible to syntax highlight automatically
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: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:18 -!- ais523_non-admin has joined.
20:16:25 <Deewiant> AnMaster: and then the 'cbreak' which breaks the next time it hits a given char
20:16:53 <AnMaster> Enter cell value to break on: j
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:58 <AnMaster> Breaking on every cell with value 106 (0x6a), character 'j'.
20:19:10 <Deewiant> ais523_non-admin: what's with the non-adminness
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: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: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: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: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:39 <Deewiant> AnMaster: it tests wrapping with # and x, I can't expect that you do j differently :-P
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:28:04 <Deewiant> I'd argue it's more elegant, because that's essentially what x is
20:28:54 -!- Dagide has quit (Remote closed the connection).
20:28:57 <Deewiant> given that you have a working x of course :-P
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: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:37 <AnMaster> it doesn't test wrapping x twice in one instruction either does it?
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: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: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:32 <Deewiant> hmm, with x that's probably right
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:35:21 <AnMaster> you actually move with a while loop :(
20:35:56 <Deewiant> doing what I said above would be faster :-)
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:49 <AnMaster> you could interpreter that sentence as it should only jump over spaces but not other instructions
20:38:03 <Deewiant> hence the example which clarifies it
20:38:36 -!- timotiis_ has joined.
20:38:53 <AnMaster> Deewiant, you won't need to same delta even I think
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:21 <AnMaster> then you could get old again using /
20:39:32 <Deewiant> well, sure, but the / slows it down :-P
20:40:22 <Deewiant> hmm, this is the culmination of beautiful code
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: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:31 <AnMaster> you know, some languages complains about such
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:50:06 -!- timotiis has quit (Read error: 113 (No route to host)).
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:16 <AnMaster> at least it gives different results each time now
20:53:24 <AnMaster> anyone suggest a better way for srandom?
20:54:11 <AnMaster> ais523_non-admin, ok, however if you run them exactly one second after each other you get issues
20:54:35 <AnMaster> ais523_non-admin, probably not when multi tasking
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:55:09 <Deewiant> cryptographically secure random seed right there
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: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:57:13 <Deewiant> AnMaster: on every initialization, CCBI populates the function pointer arrays for all instructions and fingerprints
20:57:14 <ais523_non-admin> AnMaster: you could just use open() and read() to save on stdio overhead
20:57:25 <AnMaster> ais523_non-admin, that is true
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:58:06 <Deewiant> AnMaster: yes, I do, but I haven't bothered to do it like that
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
20:59:08 <Deewiant> ais523_non-admin: module constructors
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: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:08 <Deewiant> profile-guided optimization as well
21:01:22 <AnMaster> Deewiant, can't you do profiling with ccbi?
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: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:42 <AnMaster> when speed testing against ccbi
21:04:02 <AnMaster> ais523_non-admin, I use same that I speed test on
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:42 <AnMaster> but well I can ultra-tune it for anything
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: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: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:01 <AnMaster> ais523_non-admin, yes I know about that
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: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: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: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:30 <Deewiant> AnMaster: yes, highly-optimized C beats lowly-optimized D.
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: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:28 <AnMaster> ais523_non-admin, and also technically loading the larger program will be slower
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: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: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:24 <Deewiant> I'd argue .NET is more portable than Posix-only C :-P
21:14:57 <AnMaster> Deewiant, no because mono doesn't work on all POSIX
21:15:06 <AnMaster> and even windows can do some POSIX I bet
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: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: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:50 <AnMaster> ais523_non-admin, wait a second, you made DJGPP!?
21:18:27 <AnMaster> I'll always been thinking that DJGPP = cygwin gone insane
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:21:40 <AnMaster> ais523_non-admin, err exec would replace current process
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: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:29 <AnMaster> those would not work under DJGPP
21:23:47 <AnMaster> ais523_non-admin, see man pages, but on linux, basically none iirc
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:26:08 <AnMaster> and I remember it was such a issue they merged several system services in xp into a single process
21:26:42 <AnMaster> Deewiant, windows wouldn't handle 156 processes would it?
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:30 <AnMaster> ais523_non-admin, oh btw, I got everything between 78 and 156, depending on what user I run it under
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?
22:00:01 <AnMaster> ais523_non-admin, as for $ and #
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: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:24 <AnMaster> programs could end before they got read and so on
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").