I don’t really know how it’s being held in place. Magic!
]]>
I don’t really know how it’s being held in place. Magic!
]]>Combine bzr-loom with shelf and you can handle any sort of interruptions in your workflow without having to manually keep track of uncommitted changes.
One downside of bzr-loom is the terminology. bzr combine-thread actually destroys the thread tossing all the changes made in it, which can be unpleasantly surprising. There’s a bug about it, though.
Combine bzr-loom with shelf and you can handle any sort of interruptions in your workflow without having to manually keep track of uncommitted changes.
One downside of bzr-loom is the terminology. bzr combine-thread actually destroys the thread tossing all the changes made in it, which can be unpleasantly surprising. There’s a bug about it, though.
## Install bzr-loom using `bzr branch lp:bzr-loom` in your .bazaar/plugins/ # Create a new repository $ bzr init bzr $ cd bzr # Create a new file $ echo initial > first # Check it in $ bzr add first added first $ bzr ci -m "initial" Committing to: /home/tro/temp/bzr/ added first Committed revision 1. $ cat first initial # Set the branch nick specifically. This is the initial development "thread". $ bzr nick initial # Create a loom. From this point on, you have to have the plugin to interact with this repo directly $ bzr loomify # Only one thread exists right now $ bzr show-loom =>initial # Add a new thread (acts as another branch inside the current directory) $ bzr create-thread feature-1 # Add a new file $ echo "second file" > second $ bzr add second added second $ bzr ci -m "+second" Committing to: /home/tro/temp/bzr/ added second Committed revision 2. # Switch back to the initial dev thread. Note how "second" disappears, since it is in another thread. $ bzr down-thread All changes applied successfully. Moved to thread 'initial'. $ bzr show-loom feature-1 =>initial $ ls first # Switch to feature-1 $ bzr up-thread # this would do a merge, if any new changes were made in "initial" $ ls first second # Edit first $ echo "edit in feature-1 thread" >> first $ cat first initial edit in feature-1 thread $ bzr ci -m "useless text meant to illustrate merging between threads" # At this point pretend that we are satisfied with the changes in "feature-1" # and want to merge them into "initial". Go there. $ bzr down-thread $ ls first $ bzr merge -r thread:feature-1 . +N second M first All changes applied successfully. # Merged changes from feature-1 to initial $ ls first second $ cat first initial edit in feature-1 thread $ cat second second file
This gives you a limited git-like ability to spawn off new branches in the current directory.
]]>## Install bzr-loom using `bzr branch lp:bzr-loom` in your .bazaar/plugins/ # Create a new repository $ bzr init bzr $ cd bzr # Create a new file $ echo initial > first # Check it in $ bzr add first added first $ bzr ci -m "initial" Committing to: /home/tro/temp/bzr/ added first Committed revision 1. $ cat first initial # Set the branch nick specifically. This is the initial development "thread". $ bzr nick initial # Create a loom. From this point on, you have to have the plugin to interact with this repo directly $ bzr loomify # Only one thread exists right now $ bzr show-loom =>initial # Add a new thread (acts as another branch inside the current directory) $ bzr create-thread feature-1 # Add a new file $ echo "second file" > second $ bzr add second added second $ bzr ci -m "+second" Committing to: /home/tro/temp/bzr/ added second Committed revision 2. # Switch back to the initial dev thread. Note how "second" disappears, since it is in another thread. $ bzr down-thread All changes applied successfully. Moved to thread 'initial'. $ bzr show-loom feature-1 =>initial $ ls first # Switch to feature-1 $ bzr up-thread # this would do a merge, if any new changes were made in "initial" $ ls first second # Edit first $ echo "edit in feature-1 thread" >> first $ cat first initial edit in feature-1 thread $ bzr ci -m "useless text meant to illustrate merging between threads" # At this point pretend that we are satisfied with the changes in "feature-1" # and want to merge them into "initial". Go there. $ bzr down-thread $ ls first $ bzr merge -r thread:feature-1 . +N second M first All changes applied successfully. # Merged changes from feature-1 to initial $ ls first second $ cat first initial edit in feature-1 thread $ cat second second file
This gives you a limited git-like ability to spawn off new branches in the current directory.
]]>Video editing on Linux sucks. I used Cinerella to make this. Issues encountered:
To give it credit though, the docs are pretty decent.
I spent way too much time making it all work. Next time, I’ll just find a Mac that I can use to do this.
]]>Video editing on Linux sucks. I used Cinerella to make this. Issues encountered:
To give it credit though, the docs are pretty decent.
I spent way too much time making it all work. Next time, I’ll just find a Mac that I can use to do this.
]]>using namespace std; #include <string> inline string trim(const string& o) { string ret = o; const char* chars = "\n\t\v\f\r "; ret.erase(ret.find_last_not_of(chars)+1); ret.erase(0, ret.find_first_not_of(chars)); return ret; }
It returns a new string, sort of like it’s done in Qt or Java.
]]>using namespace std; #include <string> inline string trim(const string& o) { string ret = o; const char* chars = "\n\t\v\f\r "; ret.erase(ret.find_last_not_of(chars)+1); ret.erase(0, ret.find_first_not_of(chars)); return ret; }
It returns a new string, sort of like it’s done in Qt or Java.
]]>
I don’t really know how it’s being held in place. Magic!
]]>
I don’t really know how it’s being held in place. Magic!
]]>I just stumbled upon this issue (“database is locked”), so I’m posting in case someone googles for this.
With Pysqlite, the default isolation level is DEFERRED, which means that for all write statements (INSERT/UPDATE/etc.) pysqlite implicitly opens a transaction and you have to commit it to allow other writers to proceed. Apparently, when committing the writer thread holds a global lock, not just a write lock, which prevents readers from making progress too. This lock is held even if your transaction only has SELECT (read) statements. So you have to explicitly commit those transactions.
So, I thought, hey, why not just make all my SELECT statements execute within “autocommit” connections (isolation_level=None)? Turns out that you have to close the connection explicitly after executing a SQL query even in autocommit mode to unlock the db for other threads:
con = getDBConnFromSomewhere(isolation_level=None) c = con.cursor() res = c.execute("SELECT ...") # do something with result c.close() con.close() # this is important
I just stumbled upon this issue (“database is locked”), so I’m posting in case someone googles for this.
With Pysqlite, the default isolation level is DEFERRED, which means that for all write statements (INSERT/UPDATE/etc.) pysqlite implicitly opens a transaction and you have to commit it to allow other writers to proceed. Apparently, when committing the writer thread holds a global lock, not just a write lock, which prevents readers from making progress too. This lock is held even if your transaction only has SELECT (read) statements. So you have to explicitly commit those transactions.
So, I thought, hey, why not just make all my SELECT statements execute within “autocommit” connections (isolation_level=None)? Turns out that you have to close the connection explicitly after executing a SQL query even in autocommit mode to unlock the db for other threads:
con = getDBConnFromSomewhere(isolation_level=None) c = con.cursor() res = c.execute("SELECT ...") # do something with result c.close() con.close() # this is important
SQLite has three isolation levels: DEFERRED, IMMEDIATE and EXCLUSIVE. The default is DEFERRED. Since SQLite requires a global db lock to commit writes, you can only have one writer per database with many potential readers. The levels seem to work like this:
Does this sound right?
]]>SQLite has three isolation levels: DEFERRED, IMMEDIATE and EXCLUSIVE. The default is DEFERRED. Since SQLite requires a global db lock to commit writes, you can only have one writer per database with many potential readers. The levels seem to work like this:
Does this sound right?
]]>Cannot insert breakpoint 0. Error accessing memory address 0x0: Input/output error.
Running GDB from the command line on the binary works fine. I just found that NetBeans 6.0 with the C++ plugin works fine as well. I wonder what’s wrong with Eclipse and KDevelop. Could be the way they try to interface with GDB.
]]>Cannot insert breakpoint 0. Error accessing memory address 0x0: Input/output error.
Running GDB from the command line on the binary works fine. I just found that NetBeans 6.0 with the C++ plugin works fine as well. I wonder what’s wrong with Eclipse and KDevelop. Could be the way they try to interface with GDB.
]]>20:26:50 up 48 days, 23:46, 6 users, load average: 111.92, 104.49, 104.97
They say that the load on the server is “still within acceptable levels”.
Update: they fixed the problem. Apparently it was a file-server issue causing slow I/O
]]>20:26:50 up 48 days, 23:46, 6 users, load average: 111.92, 104.49, 104.97
They say that the load on the server is “still within acceptable levels”.
Update: they fixed the problem. Apparently it was a file-server issue causing slow I/O
]]>TODO:
TODO:
handle_read() when the data is available.
import asyncore, socket from dns import resolver, rdatatype, rdataclass, message class AsyncDNS(asyncore.dispatcher): def __init__(self): asyncore.dispatcher.__init__(self) self.r = resolver.Resolver() self.query = '' self.create_socket(socket.AF_INET, socket.SOCK_DGRAM) self.connect((self.r.nameservers[0], self.r.port)) def makeQuery(self, server): self.query = message.make_query('_xmpp-server._tcp.%s' % server, rdatatype.SRV, rdataclass.IN).to_wire() def writable(self): return (len(self.query) > 0) def handle_read(self): data = self.recv(4096) answer = message.from_wire(data) print answer.answer[0].to_text() def handle_write(self): self.send(self.query) self.query = '' def handle_accept(self): pass def handle_connect(self): pass def handle_bind(self): pass def handle_close(self): self.close() if __name__ == "__main__": d = AsyncDNS() d.makeQuery('livejournal.com') asyncore.loop()
handle_read() when the data is available.
import asyncore, socket from dns import resolver, rdatatype, rdataclass, message class AsyncDNS(asyncore.dispatcher): def __init__(self): asyncore.dispatcher.__init__(self) self.r = resolver.Resolver() self.query = '' self.create_socket(socket.AF_INET, socket.SOCK_DGRAM) self.connect((self.r.nameservers[0], self.r.port)) def makeQuery(self, server): self.query = message.make_query('_xmpp-server._tcp.%s' % server, rdatatype.SRV, rdataclass.IN).to_wire() def writable(self): return (len(self.query) > 0) def handle_read(self): data = self.recv(4096) answer = message.from_wire(data) print answer.answer[0].to_text() def handle_write(self): self.send(self.query) self.query = '' def handle_accept(self): pass def handle_connect(self): pass def handle_bind(self): pass def handle_close(self): self.close() if __name__ == "__main__": d = AsyncDNS() d.makeQuery('livejournal.com') asyncore.loop()
A bunch of these are so obvious they don’t say much at all, but it just seems like Alan couldn’t stop cranking them out after the first few.
]]>A bunch of these are so obvious they don’t say much at all, but it just seems like Alan couldn’t stop cranking them out after the first few.
]]>
Basically, yes.
]]>
Basically, yes.
]]>
Come to your own conclusions…
]]>
Come to your own conclusions…
]]>This is all exciting as my CSC490 project involves creating a Python-based XMPP framework (disguised as a server).
]]>This is all exciting as my CSC490 project involves creating a Python-based XMPP framework (disguised as a server).
]]>
This graph was generated using gnuplot-workrave. The steady slope from 2005 to 2006 is caused by too little data between the two extremes. I think I didn’t have workrave running during that time. The recent drop was due to the holidays.
]]>
This graph was generated using gnuplot-workrave. The steady slope from 2005 to 2006 is caused by too little data between the two extremes. I think I didn’t have workrave running during that time. The recent drop was due to the holidays.
]]>
Now to find the time to read both before the semester starts.
]]>
Now to find the time to read both before the semester starts.
]]>
]]>
]]>