search of the:   for: 
code logs -> 2010 -> Tue, 23 Mar 2010< code.20100322.log - code.20100324.log >
--- Log opened Tue Mar 23 00:00:42 2010
00:23
<@Vornicus>
Yay forkbomb!
00:27 Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code
00:29 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code
01:25
<@Vornicus>
clemin: if you have an error in your php, some webservers are set up to not show you the error.
01:29
< celticminstrel>
Through various fiddlings, I determined that it was most likely a syntax error.
01:30
< celticminstrel>
More recently I had the problem that $_POST was empty.
02:27 Attilla [Attilla@FBC920.642D35.7B2B85.11BB86] has quit [Connection reset by peer]
02:28 Serah [Z@26ECB6.A4B64C.298B52.D80DA0] has quit [[NS] Quit: The world is so funny sometimes; I often forget to laugh.]
02:28 * Orthia pokes Vorn timidly.
02:30 Serah [Z@26ECB6.A4B64C.298B52.D80DA0] has joined #code
02:30
<@Vornicus>
?
02:35
< Orthia>
Vorn: My brain has decided to cause me a few problems this week. I admit, I should have seen it coming, but it is problematic all the same. Would you be willing to treat me like an idiot and help me with this LZW code? Trying to use python as the template is a wonderful idea, but trying to convert between the two languages is sort of not working well.
02:38
<@Vornicus>
Okay.
02:39
<@Vornicus>
So let's deal with encoding a string.
02:40
<@Vornicus>
FirWe,, not a string, a byte sequence.
02:40
<@Vornicus>
wow, that was good.
02:40
<@Vornicus>
Well*
02:41
< Orthia>
OK
02:43
<@Vornicus>
LZW depends on the existence of a dictionary of byte-sequence-chunks, and loading that dictionary with stuff that we've seen. Our first step is to load up that dictionary.
02:43
< Orthia>
Logical.
02:43
<@Vornicus>
Well, to load up that dictionary with all the length-1 byte sequences.
02:44
<@Vornicus>
By doing this we make it so we don't have to carry around our starting dictionary in our file - our encoder and decoder pair know what the dictionary starts with, and that's good enough.
02:45
<@Vornicus>
Now, our problem here is that our encoder only works in nonnegative numbers, and bytes happen to be signed.
02:47
<@Vornicus>
fortunately, we know the smallest byte we can use: -128, also called Byte.MIN_VALUE
02:48
< Orthia>
... so instead of 0 to 256, we will be going from Byte.MIN_VALUE to Byte.MAX_VALUE
02:48
<@Vornicus>
So we're going to load up our dictionary - which is to say, a Tree that we made - with bytes from -128 to 127, and with codes from 1 to 256. code 0 is reserved for the stop code; we do kind of need that.
02:49
<@Vornicus>
(later we're going to want to add a clear code as well; it will probably end up being 1, but it's a minor adjustment we can do after we've done the core algorithm)
02:52
< Orthia>
hmm. I see.
02:52
< Orthia>
Is there a Byte.NEXT_VALUE equivalent?
02:52
< Orthia>
Or can you go Byte++?
02:52
<@Vornicus>
my_byte++
02:52
<@Vornicus>
Easier way to do that
02:53
<@Vornicus>
er.
02:53 Serah [Z@26ECB6.A4B64C.298B52.D80DA0] has quit [Ping timeout: 121 seconds]
02:54
< Orthia>
OK
02:54
<@Vornicus>
An easier way to do this though is to iterate from 0 to 255, and then add Byte.MIN_VALUE to the result, and then cast the whole shebang to a byte.
02:55
< celticminstrel>
Isn't the next_value stuff only really meaningful for floating-points, where it's not at all obvious what the next highest possible value is?
02:55
<@Vornicus>
and then for your codes just add 1 to the result of your iteration.
02:57
<@Vornicus>
celticminstrel: It doesn't appear that that function even exists.
02:59
< Orthia>
OK!
03:00
< celticminstrel>
I definitely recall the existence of functions that do something like that...
03:00
<@Vornicus>
So let's see that bit of code - the code that loads single bytes and their corresponding codes into the dictionary (which, by the way, is merely a Tree)
03:01
< celticminstrel>
...though it's possible it was a proposal rather than something actually in the Java library.
03:01
<@Vornicus>
it's not in there, no
03:02
< Orthia>
http://pastebin.starforge.co.uk/179
03:06
<@Vornicus>
Don't need to cast i alone there.
03:06
<@Vornicus>
also, this method is static.
03:08
<@Vornicus>
also: raw isn't a member variable but an argument variable, so remove yes; and encoded is a local variable so move it into the start of the method.
03:08
< Orthia>
'so remove yes'?
03:08
<@Vornicus>
remove "raw" where you ask //remove?
03:13
< Orthia>
Ah! Right.
03:13
< Orthia>
I was reading too literally, and going "But where is yes to remove?" >_>
03:13
< Orthia>
Sorry, my brain is doing this massively today.
03:13
<@Vornicus>
and finally: starting i at 1 here is wrong. Start it at 0, use i + 1 in the add call to get the value. The bug there is that -128 never gets a code the way it works
03:15
< Orthia>
...ok, thank you. I'd have never bloody figured that one for an age.
03:16
< Orthia>
OK.
03:17
< Orthia>
Now I need a method for a loop that takes a chunk of the data, adds it to the tree, and then records where it got added. Yes?
03:17
<@Vornicus>
Something like that, yes.
03:19 Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has joined #code
03:21
< Orthia>
hm. Cannot use raw.read() as the check whether or not the loop should continue - reading actually takes a lump out of the file, so... hm.
03:21
< Orthia>
Maybe a do-while.
03:21
<@Vornicus>
we're going to do this using a two-level loop; this keeps us in bytes, for one thing, and reduces the number of reads we do, and keeps us sane.
03:22
<@Vornicus>
In certain other ways.
03:22
<@Vornicus>
what we're going to do is we're going to have an outer loop that reads 1 kilobyte of stuff from the file, then an inner loop that loops over the stuff in our array.
03:23
< Orthia>
OK
03:24
<@Vornicus>
so we need two locals for this: int bytes_read, and byte[] buffer.
03:24
<@Vornicus>
http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read(byte[]) <--- this is the method we'll use.
03:24
< Orthia>
Hm
03:25
< Orthia>
Oh, I think I see
03:25
< Orthia>
We take things out of read() and put them into buffer, so the LZW can keep encoding?
03:26
<@Vornicus>
Sort of, yes.
03:26
< Orthia>
OK?
03:26
<@Vornicus>
read(byte[]) fills our buffer, and returns the number of things it filled the buffer with.
03:27
<@Vornicus>
So we'll do this, process the stuff we filled the buffer with, and then read some more.
03:28
< Orthia>
Hm
03:28
< Orthia>
Is there a specific size array we want?
03:28
<@Vornicus>
Not /particularly/, but I'd use 1024.
03:29
< Orthia>
Would we want to use an ArrayList instead, so it's of variable size?
03:30
<@Vornicus>
No, an actual array.
03:30
< Orthia>
OK
03:34
<@Vornicus>
(because it will be of fixed size, we'll just be putting a possibly-variable amount of data in)
03:34
< Orthia>
http://pastebin.starforge.co.uk/180
03:35
< Orthia>
read(byte[], b) is apparently expecting an ArguementList
03:36 gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?]
03:36
<@Vornicus>
What the crap dude
03:37
< Orthia>
What have I done now >_>
03:38
< celticminstrel>
Well yeah, byte[] is a type. You can't pass it to a function.
03:38
< Orthia>
Oh. Er. Oops.
03:39
< celticminstrel>
I'd suggest new byte[size], but I don't really know what you're doing there.
03:39
<@Vornicus>
pass buffer to the function; get bytes_read from it. Compare bytes_read to -1 for your outer loop's condition.
03:40
<@Vornicus>
then iterate over buffer (using bytes_read as the loop limit) for your inner loop.
03:44
< Orthia>
...Hm. Wait, I get it - Bytes_read is a counter, isn't it?
03:45
<@Vornicus>
Sort of - it tells us how many bytes we got in our latest read() attempt.
03:51
<@Vornicus>
If you have anything you should show me.
03:52
< Orthia>
hrn, sec, still nutting it out
03:54
< Orthia>
http://pastebin.starforge.co.uk/181
03:54
< Orthia>
I know it is wrong, but here's what I'm poking at.
03:55
<@Vornicus>
Yeah, not quite
03:55
<@Vornicus>
Notice the method that I linked you to - it takes a parameter b which is an array of bytes.
03:56
< Orthia>
hrm. OK. If it reads from that, then ... hn, OK
03:56
<@Vornicus>
What this method /does/ is it fills the array with stuff. Remember that arrays are thrown around by reference: by passing that array in, it modifies the array so the outside world can see it.
03:56
< Orthia>
... Ah-hah
03:57
< Orthia>
I had forgotten that aspect of arrays, it was "But why am I throwing the bit I want /out/ into the function?"
03:58
<@Vornicus>
then bytes_read tells you how full that array is.
03:59
< Orthia>
So bytes_read is essentially the same as byte[].Length(); in another world?
03:59
< Orthia>
(Yes I know it doesn't work that way)
04:00
<@Vornicus>
vaguely, yes
04:00
<@Vornicus>
It's essentially how much of the array is /valid/ - going beyond that point gets you into garbage land.
04:01
< Orthia>
hn
04:03
<@Vornicus>
(use it like you would use buffer.length if we weren't sometimes partially filling it.)
04:05
< Orthia>
So
04:05
< Orthia>
buffer[??] = raw.read(buffer);
04:05
<@Vornicus>
bytes_read = raw.read(buffer)
04:06
< Orthia>
...ah-/hah/
04:06
< Orthia>
Because .read will output the number of bits it chomped, and it will try to fill the array to full if at all possible - correct?
04:06 * Orthia was just figuring it out.
04:06
< celticminstrel>
And buffer is passed by reference, of course...
04:07
< Orthia>
Yeah. I kept forgetting that bit.
04:07
<@Vornicus>
Precisely
04:07
< Orthia>
So, ok
04:07
< Orthia>
That fills our buffer and tells me how much data is in the buffer.
04:08
<@Vornicus>
Yep.
04:08
< Orthia>
We then start looping... iterating through the buffer up to bufferSize, hitting trie.add on each bit?
04:08 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: *hums* Can't stay now!]
04:08
<@Vornicus>
Not on each bit, we'll deal with that after we've got our byte looper working.
04:09
< Orthia>
OK then, what does it need to do next?
04:09
<@Vornicus>
just say //process for your actual per-byte process for now.
04:09
<@Vornicus>
Show me your code.
04:11
< Orthia>
http://pastebin.starforge.co.uk/182
04:13 Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [Ping timeout: 121 seconds]
04:14
< Orthia>
On the right track at all?
04:14
<@Vornicus>
Pretty much right.
04:15
<@Vornicus>
30 should be != -1 instead of > 0; 26 you don't need to cast i alone.
04:15
< Orthia>
Awesome.
04:16
<@Vornicus>
index should be 257, not 256.
04:18
< Orthia>
OK
04:18
< Orthia>
Those two make me think I should be using index in the for loop to cut down on breakability, but we will leave that another day
04:18
< Orthia>
Also, er. For loop halts at i < 256. Index now starts at 257. Fencepost error?
04:19
<@Vornicus>
nope.
04:19
<@Vornicus>
remember that the indexes we put into the trie were i + 1
04:20
<@Vornicus>
So we'll have indices from 1 to 256 in the trie, 0 reserved, and index waiting at 257.
04:21
< Orthia>
Oh. Funky.
04:21
<@Vornicus>
And we will /not/ be using index in the for loop directly - you'll see why in a bit.
04:21
< Orthia>
Yessir!
04:21
< Orthia>
Done all that. Want to see, or want to get to the next bit, which I'm pretty sure is the Elderitch Horror?
04:23
<@Vornicus>
The next bit is lines 10-16 in http://pastebin.starforge.co.uk/156; we'll have to fiddle with it a bit to get it into java, but it's mostly pretty straightforward.
04:23
< Orthia>
Curiously enough, I'm almost looking forward to it!
04:25
<@Vornicus>
Before we can actually /do/ this though we need to know where we currently are in the trie; I called this "current_codes", you'll probably want to call it "current_node" or something. It's a Tree, and it starts initialized to trie.
04:27
< Orthia>
...OK
04:27
< Orthia>
Is this in addition to or in replacement of my 'trie'?
04:28
<@Vornicus>
In addition to. We need to keep track of the root of the trie, because we'll head back there every time we run off the end of the existing trie.
04:28
<@Vornicus>
(which happens a lot - it's the only time we /add/ to the trie, too)
04:30
< Orthia>
In this case, if we have two trees running around, do I want to rename trie?
04:30
<@Vornicus>
No.
04:30
<@Vornicus>
well, okay, trie_root
04:31
<@Vornicus>
maybe, if you want.
04:32
< Orthia>
Righto.
04:32
<@Vornicus>
Now that we have that set up we can tell the inner loop what to do.
04:32
< Orthia>
Tree currentNode = new Tree(); ?
04:33
< Orthia>
Also, is this inside the loop or a function variable?
04:37
<@Vornicus>
no, tree currentNode = trie_root
04:37
<@Vornicus>
and it's a function-wide variable.
04:38
< Orthia>
Yessir.
04:39
<@Vornicus>
we use current_node to search down the trie as we move through the buffer. Which brings us, finally, to what we're actually doing here.
04:39
< Orthia>
Aha! OK.
04:44
<@Vornicus>
We need to search in current_node for the current byte.
04:46
< Orthia>
.seek, right?
04:47
< Orthia>
No, that's not right.
04:47
<@Vornicus>
no, that is right.
04:48
< Orthia>
http://pastebin.starforge.co.uk/183 - Do I still want to be adding crap to rootTrie ?
04:48
< Orthia>
Or trieRoot or whatever I called it.
04:48
<@Vornicus>
trieRoot? no, that stuff is Wrong
04:50
< Orthia>
Delete entirely, start fresh?
04:50
<@Vornicus>
Those two inner lines should be deleted, yes.
04:51
< Orthia>
Replaced with: currentNode.seek(buffer[i]);
04:51
<@Vornicus>
All right, we need to assign the result of that to something; dunno what to call it, but it's a TreeNode, and we're going to extract some things from it.
04:51
< Orthia>
Hm
04:52
< Orthia>
So wait, currentNode should probably be currentTree
04:52
< Orthia>
Then we can have currentNode within the tree?
04:52
<@Vornicus>
....sure, works for me.
04:53
< Orthia>
And currentNode is a TreeNode we have called from within the currentTree, correct?
04:53
< Orthia>
- Are we /able/ to call individual Nodes?
04:53 * Orthia checks.
04:54
< Orthia>
Oh, hey.
04:54
< Orthia>
seek returns the TreeNode anyway. Handy.
04:55
< Orthia>
currentNode = currentTree.seek(buffer[i]);
04:55
<@Vornicus>
We're able to talk about individual nodes; seek does return it.
04:55
< Orthia>
(God but I love Eclipse and 'refactor'
04:57
<@Vornicus>
okay. Now, we need to check whether curentNode is null or not. I'd start with if (currentNode != null), it's the more common case.
04:58
< Orthia>
Righto
04:59
< Orthia>
And then inside, if it is not Null, we want to start doing Stupid Pet Tricks.
05:00
<@Vornicus>
these tricks aren't that stupid
05:00
< Orthia>
righto
05:00
<@Vornicus>
We need to set current_tree to current_node.getChild() or whatever it's called
05:01
<@Vornicus>
and we need an int current_index (which is to say, the index that this would encode to, not the index that we'd next add to the tree) to store current_node.getIndex or whatever it's called
05:01
< Orthia>
...oh. Oh, that's clever.
05:02
<@Vornicus>
This way when we get to the /next/ character, if that one takes us off the end of the tree, we can encode the previous sequence of characters.
05:04
<@Vornicus>
once you've put that in, show me your code.
05:08
< Orthia>
http://pastebin.starforge.co.uk/184
05:08
< Orthia>
That took like four minutes to bloody upload.
05:08
<@Vornicus>
Yeesh
05:09
<@Vornicus>
anyway that's not wrong unless those are the wrong words, that's perfectly sensible.
05:09
<@Vornicus>
And that's /all we do/ if we're still living in the trie. Time fore...
05:09
<@Vornicus>
ELSE
05:09
<@Vornicus>
AND THE ALTERNATIVE CONDITIONS
05:10
<@Vornicus>
...is possibly the shittiest band name ever.
05:10
< Orthia>
My one concern is thus: We are returning the index of the current node, and the /child/ of that node, not the childs index.
05:10
<@Vornicus>
Right. the child is a tree, it doesn't have an index.
05:11
<@Vornicus>
And we want the index of the current node: this way, the next time, if we have run off the end of the tree, everything /before/ we ran off the end gets encoded.
05:12
<@Vornicus>
Did that make sense?
05:12
< Orthia>
Aha, it does. I was just checking it was doing what we thought it was doing.
05:13
<@Vornicus>
OKay, anyway, on to our else.
05:15
< Orthia>
Right!
05:15
<@Vornicus>
If we get the else, then current_node is null; this means that we've run off the end of the tree!
05:16
<@Vornicus>
Which means we are ready to encode.
05:18 gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code
05:20
<@Vornicus>
so, 1. we add current_index (which is to say, the code index for the /previous sequence of bytes/) to encoded; 2. we add the current byte and index to current_tree; 3. we increment index (because we've used this index to make a new code; 4. start again from the trie_root and follow the path for the current byte.
05:21
<@Vornicus>
1 2 and 3 are 1-liners; 4 is the three lines we used to get and apply current_node, except we use trie_root instead of current_tree
05:24
< Orthia>
hrn
05:25
<@Vornicus>
2 is the actual trick to LZW - we're adding the previous sequence /plus/ this latest character to the dictionary of codes we know.
05:26
< Orthia>
OK, query: In the else, currentIndex is not set to anything previously. Yes?
05:26
<@Vornicus>
current_index is set to something /by the previous run through the loop/
05:26
< Orthia>
Aaaah.
05:26
<@Vornicus>
as is current_tree
05:26
< Orthia>
It is erroring out of fear that it may not have been initalised.
05:27
< Orthia>
Oh, duh. I never set it to /anything/.
05:27
<@Vornicus>
Initialize it at the top of the function. 0, I guess.
05:27
< Orthia>
0 is our stop code~
05:27
<@Vornicus>
YOu're right!
05:28
<@Vornicus>
but here's the thing: the first byte will /always/ go through the if.
05:28
< Orthia>
Or is this a matter of 'we are confident we will have run through once previously', and if we /haven't/, it's time to stop anyway?
05:28
<@Vornicus>
It is indeed.
05:30
< Orthia>
2: We're adding in the current buffer byte, and the currentIndex?
05:30
<@Vornicus>
and index, not current_index
05:30
<@Vornicus>
index tells us the next thing we add to the trie; current_index tells us the next thing we'll potentially add to encoded.
05:31
< Orthia>
Oh, yes.
05:31
<@Vornicus>
These might not be the best names.
05:31
< Orthia>
We will fix them in a second then~
05:32
< Orthia>
Up to 4.
05:32
<@Vornicus>
4, well, here, let me show you the difference in python.
05:32
< Orthia>
Hrn. What 4 lines?
05:33
<@Vornicus>
current_index, current_codes = current_codes[c]
05:33
<@Vornicus>
That's in the if.
05:33
<@Vornicus>
current_index, current_codes = codes_root[c]
05:33
<@Vornicus>
and that's in the else.
05:34
< Orthia>
Oh, right
05:34
< Orthia>
We want to start iterating from the root again instead of continuing down the branches, yes?
05:34
<@Vornicus>
yep.
05:34
<@Vornicus>
because we ran off the end of the tree.
05:36
<@Vornicus>
this comes out to three lines in Java; note that the three lines you already have are broken up by an if.
05:37
< Orthia>
Hrn. How do I reset currentNode?
05:37
<@Vornicus>
How do you set current_node originally?
05:38
< Orthia>
gottit
05:38
<@Vornicus>
Show me the code.
05:39
< Orthia>
http://pastebin.starforge.co.uk/185
05:39
<@Vornicus>
If it's right, we're three lines from victory.
05:39
< Orthia>
Is that correct?
05:39
< Orthia>
It looks like you could factorise a couple chunks of it, but we'll leave it for the moment
05:39
<@Vornicus>
Not quite
05:39
< Orthia>
OK, where'd I go wrong
05:39
< Orthia>
(And after this we will have to finish I think ,but thank you thank you thank you, sir)
05:39
<@Vornicus>
delete 43 - we won't set currentTree yet
05:40
<@Vornicus>
then in what's currently called 44 use trieRoot instead of currentTree
05:40
<@Vornicus>
and then after that set currentTree to currentNode.getChild();
05:42
< Orthia>
right
05:42
<@Vornicus>
All right.
05:42
<@Vornicus>
And that is everything we do in the loop.
05:42
<@Vornicus>
Now there's two things left to do.
05:42
<@Vornicus>
1. we need to encode the last few bits.
05:43
<@Vornicus>
2. we need to send the stop code.
05:43
< Orthia>
And we need to actually add these wonderful indexes to the string.
05:43
<@Vornicus>
well. 3. we need to return the encoded.
05:43
<@Vornicus>
packing is another matter. We won't do that in this function.
05:44
< Orthia>
No we won't.
05:44
<@Vornicus>
so first off: when we hit the end of the loop, we need to add the index for the last few bytes to our list of indices.
05:44
< Orthia>
Right
05:45
<@Vornicus>
This should be trivial.
05:45
< Orthia>
else {...} encoded.add(currentIndex);
05:45
< Orthia>
?
05:46
<@Vornicus>
not outside the else.
05:46
<@Vornicus>
outside /the entire loop/
05:46
<@Vornicus>
indeed, even outside the /outer/ loop.
05:46
<@Vornicus>
This happens when there is absolutely nothing left at all to look at.
05:47
< Orthia>
So we only add things to the encoded string when we are about to return it?
05:47
< Orthia>
'cuz once you're outta the loop, yer done.
05:48
<@Vornicus>
Well - we add things to the encoded string when we run off the tree, and when we run out stuff entirely, which is when we're about to return it.
05:48
< Orthia>
Oh I see, the else does it too. Okay. Carry on.
05:48
< Orthia>
Next step?
05:49 * Orthia hates to be impatient, but is getting poked to cook dinner, so will be ending this after this, he suspects~
05:49
<@Vornicus>
Next step.
05:49
<@Vornicus>
Stop code!
05:51
< Orthia>
if(currentIndex = 0) rootTree = new Tree(); ?
05:51
<@Vornicus>
...what
05:51
< Orthia>
OK, I think we might want to leave this till later then, 'cuz my brain is fried.
05:51
<@Vornicus>
This is the /stop code/
05:51
< Orthia>
Also I am being waved at by my guests~
05:51
<@Vornicus>
all we're doing is throwing it on to the encoding.
05:51
< Orthia>
Oh, right.
05:52
<@Vornicus>
The clear code requires some rather interesting reengineering, and we're not doing it now.
05:52
< Orthia>
OK
05:52
< Orthia>
encoded.add(0);
05:52
<@Vornicus>
Bingo.
05:52
<@Vornicus>
And then we return, and VICTORY
05:53
< Orthia>
It's done?
05:53
< Orthia>
Sweet.
05:53
< Orthia>
Thank you thank you thank you, mister Vorny
05:53
< Orthia>
I will now leave you to sleep, and myself go flomp into lounge to get food, for I am meant to be getting food~
05:54
<@Vornicus>
laters
05:54
< Orthia>
http://pastebin.starforge.co.uk/186 - ze nights work. Thank you!
05:56
<@Vornicus>
next up is decode, then there's pack and unpack, and then we get to suss out clear codes.
05:57
<@Vornicus>
decode is relatively straightforward but there's a fiddly exception; pack and unpack I haven't even tried to do yet.
06:00
<@Vornicus>
clear codes, there is a problem that gets kind of glossed over in the assignment.
06:02
<@Vornicus>
well, two problems. 1. clearing at any loss in efficiency at all means that any time we end up dropping a first- or second- level index it'd clear, so better is to wait for the efficiency to drop 5%. 2. the unpacker doesn't have enough information to know when you clear unless you pass a clear code itself.
06:04 AnnoDomini [annodomini@Nightstar-688fac12.adsl.tpnet.pl] has joined #code
06:04 mode/#code [+o AnnoDomini] by Reiver
06:10
<@Vornicus>
(or some other amount. I picked 5% because it seems a convenient amount.)
06:47 Vornicus is now known as Vornicus-Latens
07:10 You're now known as TheWatcher
08:13 You're now known as TheWatcher[afk]
09:00 Rhamphoryncus [rhamph@Nightstar-8931f88f.abhsia.telus.net] has quit [Client exited]
09:16 Orthia [orthianz@Nightstar-04ecdbee.xnet.co.nz] has quit [Client closed the connection]
09:32 Orthia [orthianz@Nightstar-04ecdbee.xnet.co.nz] has joined #code
09:38 Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [Client closed the connection]
10:10 You're now known as TheWatcher
10:21 Beaver [guest@583787.B5B398.0F5279.CF6C9A] has joined #code
10:21 Beaver [guest@583787.B5B398.0F5279.CF6C9A] has quit [G-Lined: Spamming/Advertising]
10:25 Attilla [Attilla@FBC920.642D35.7B2B85.11BB86] has joined #code
10:25 mode/#code [+o Attilla] by Reiver
10:26 AnnoDomini [annodomini@Nightstar-688fac12.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds]
10:28 AnnoDomini [annodomini@Nightstar-af2cc94e.adsl.tpnet.pl] has joined #code
10:28 mode/#code [+o AnnoDomini] by Reiver
11:13 Orth [orthianz@Nightstar-ca0ee0f8.xnet.co.nz] has joined #code
11:14 REGIS_mark_V [WhyNot@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds]
11:14 REGIS_mark_V [WhyNot@NetworkAdministrator.Nightstar.Net] has joined #code
11:15 Orthia [orthianz@Nightstar-04ecdbee.xnet.co.nz] has quit [Ping timeout: 121 seconds]
11:30 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code
11:30 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [Client exited]
12:48 Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has joined #code
13:34 REGIS_mark_V is now known as PinkFreud
13:48 You're now known as TheWatcher[d00m]
13:54 Orthia [orthianz@Nightstar-832e0407.xnet.co.nz] has joined #code
13:56 Orth [orthianz@Nightstar-ca0ee0f8.xnet.co.nz] has quit [Ping timeout: 121 seconds]
14:07 celticminstrel [celticminstre@1AB00B.855209.A256BB.B16D09] has joined #code
14:28 Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [Ping timeout: 121 seconds]
15:06 You're now known as TheWatcher[afk]
15:09 Serah [Z@26ECB6.A4B64C.298B52.D80DA0] has joined #code
15:51 celticminstrel [celticminstre@1AB00B.855209.A256BB.B16D09] has quit [Client exited]
15:54 * SmithKurosaki hugs
15:55 * Vornicus-Latens hugs Smith
15:55
< SmithKurosaki>
lol
15:55
< SmithKurosaki>
So /ame sends it to all chans you are in, interesting
15:56
< gnolam>
You just typoed it, then, or what? :)
15:57
< SmithKurosaki>
Yea
15:57
< SmithKurosaki>
I wanted to type /me, but typed /ame and now its in all my chans in all my networks
16:48 Syloqs-AFH [Syloq@NetworkAdministrator.Nightstar.Net] has quit [Connection reset by peer]
16:52 Syloqs_AFH [Syloq@NetworkAdministrator.Nightstar.Net] has joined #code
16:54 Syloqs_AFH is now known as Syloqs-AFH
17:10 Attilla [Attilla@FBC920.642D35.7B2B85.11BB86] has quit [Ping timeout: 121 seconds]
17:13 Attilla [Attilla@FBC920.DDABA2.4E6AE9.B3BF85] has joined #code
17:13 mode/#code [+o Attilla] by Reiver
17:21 Rhamphoryncus [rhamph@Nightstar-8931f88f.abhsia.telus.net] has joined #code
17:47 celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code
17:58 You're now known as TheWatcher
18:07 Serah [Z@26ECB6.A4B64C.298B52.D80DA0] has quit [Ping timeout: 121 seconds]
18:27 Vornicus-Latens is now known as Vornicus
18:31 Serah [Z@26ECB6.A4B64C.298B52.D80DA0] has joined #code
21:45 McMartin [mcmartin@Nightstar-6397d65b.pltn13.sbcglobal.net] has quit [Client closed the connection]
21:50
< Rhamphoryncus>
heh awesome. I just found some code that would be simplified by swapping the class on an instance, as a way of changing modes
21:51
< Rhamphoryncus>
An article on prototyping (as an alternative to classes) was promoting that approach. Of course they claimed it was a special ability of prototyping
21:53 McMartin [mcmartin@Nightstar-3c130f1a.pltn13.sbcglobal.net] has joined #code
21:53 mode/#code [+o McMartin] by Reiver
22:11
<@ToxicFrog>
"Swapping the class on an instance"?
22:29
< Rhamphoryncus>
class Foo(object): pass; class Bar(object): pass; x = Foo(); x.__class__ = Bar
22:29
< Rhamphoryncus>
replacing the type pointer
22:32
<@McMartin>
Morphing is bad, bad.
22:32 * McMartin whaps Rhamphoryncus with a rolled-up newspaper
22:32
< Rhamphoryncus>
oh I agree
22:32
< Rhamphoryncus>
That's why I'm so entertained
22:33
< Rhamphoryncus>
These aren't public classes, so there's no chance of any further subclassing. This is the only modal state involved. It would work perfectly
22:35
< Rhamphoryncus>
http://pastebin.starforge.co.uk/188
22:40
< Rhamphoryncus>
http://pastebin.starforge.co.uk/189
22:43
< Rhamphoryncus>
oops forgot to remove the mode assignment in __init__
22:45
< Rhamphoryncus>
and come to think of it, temp_watches is supposed to be a common attribute.. not that I recall what it's for
22:46
< Rhamphoryncus>
The whole morphing thing wouldn't be so bad if you had multiple delegates you swap, rather than just a single __class__ attribute to swap
22:47
<@McMartin>
If you have a reassignable delegate object, that isn't morphing
22:48
< Rhamphoryncus>
If the delegate object is empty and the compiler optimizes it down to just a type pointer...
22:49
< Rhamphoryncus>
Actually, not empty, but rather a union
22:49
<@McMartin>
If it's empty, it's not a delegate~
22:49
< Rhamphoryncus>
An inlined delegate
22:50
<@McMartin>
Any member in C++ is "inlined".
22:50
<@McMartin>
The whole point is that you're looking up the type pointer and getting the method to call.
22:50
<@McMartin>
If this is *purely* for RTTI, you're doing something *else* terribly wrong.
22:50
< Rhamphoryncus>
No, the point is that the compiler is doing it for me :) Hypothetically
22:51
< Rhamphoryncus>
There's no language that does it in such a fashion
22:52
<@McMartin>
Violating type safety in C++ will let you forcibly reassign the vtable pointer
22:56
< Rhamphoryncus>
http://pastebin.starforge.co.uk/190
22:57 AnnoDomini [annodomini@Nightstar-af2cc94e.adsl.tpnet.pl] has quit [[NS] Quit: Sleep.]
22:58
< Rhamphoryncus>
The advantage is you can group the methods for a mode togoether, rather than having a tree of if-statements in every method
22:59
< Rhamphoryncus>
Disadvantages include not being extensible, but I don't think the tree of if-statements ie extensible either
23:00
< Rhamphoryncus>
it is a niche tool, albeit perfect for this job. Does it generalize to other finite state machines?
23:06
< Rhamphoryncus>
eww hey, there's a semicolon in my soup!
23:20 gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?]
23:39 You're now known as TheWatcher[T-2]
23:42 You're now known as TheWatcher[zZzZ]
--- Log closed Wed Mar 24 00:00:43 2010
code logs -> 2010 -> Tue, 23 Mar 2010< code.20100322.log - code.20100324.log >
 search of the:   for: