<seoaqua>
zenspider, thanks, but chrome is able to open it, so that's a trick ?
<niklasb>
seoaqua: chrome is just too smart for its own good.
<zenspider>
seoaqua: just because chrome can open in doesn't make it a uri
rdavila has joined #ruby-lang
<seoaqua>
zenspider, ok got it :(
<seoaqua>
zenspider, so the only format of % stings are %[0-9A-F]{2} ?
jakko has joined #ruby-lang
srbartlett has joined #ruby-lang
peppyheppy has joined #ruby-lang
peppyheppy has quit [#ruby-lang]
shevy has joined #ruby-lang
slyphon has joined #ruby-lang
Clordio has joined #ruby-lang
srbaker has joined #ruby-lang
Tearan has joined #ruby-lang
jtoy has joined #ruby-lang
gregmore_ has joined #ruby-lang
srbaker has joined #ruby-lang
renato has joined #ruby-lang
srbaker has joined #ruby-lang
Swimming_Bird has joined #ruby-lang
Hakon|mbp has joined #ruby-lang
Radium has joined #ruby-lang
jmcphers has joined #ruby-lang
ryanf has joined #ruby-lang
kensei has joined #ruby-lang
jmcphers has joined #ruby-lang
tomzx has joined #ruby-lang
shtirlic_ has joined #ruby-lang
spuk has joined #ruby-lang
jstr has joined #ruby-lang
jakko has joined #ruby-lang
jakko has joined #ruby-lang
<Xzyx987X>
this is perhaps not even a ruby specific question, but what is the best way in ruby to create a file that will be deleted when closed? it only has to work on *nix, but it would be nice if it worked in windows too
<erikh>
ri Tempfile
dumfries has joined #ruby-lang
<Xzyx987X>
that doesn't work because I need to be able to control the file name. I also need to make sure it is deleted exactly when it is closed and no later. I don't think tempfile does that
<Xzyx987X>
what I am really trying to do here is create a class that will allow me to lock objects across seporate processes based on an id. maybe there is a better way to go about it, but file locks were the first thing I thought of
jarred has joined #ruby-lang
jmcphers has joined #ruby-lang
jakko has joined #ruby-lang
dumfries has joined #ruby-lang
seanstickle has joined #ruby-lang
<bnagy>
how about Tempfile?
<bnagy>
did you look at Regexp.union?
<bnagy>
what does 'locking objects' mean?
<bnagy>
in general, using the filesystem is about the worst approach you could take to interprocess comms / sync
<heftig>
Xzyx987X: delete the file immediately after you open it
<heftig>
ah, nevermind, you need locking and not tempfiles
dumfries has joined #ruby-lang
<heftig>
where does that object come from? if it's from a database, use the database's locking mechanisms
<heftig>
if it's associated with a file, use flock
<Xzyx987X>
bnagy, I agree it's bad. it would make ten times more sense to do this any number of other ways. except for this particular project, I can't run an external process to manage the locks in any way, and I'm trying not to rely on anything platform specific
diegoviola has joined #ruby-lang
<Xzyx987X>
using flock is my current plan, but it still leaves me with a bunch of stray lock files, since a very common case for losing a lock would be the program exiting
<heftig>
on exit, try to grab an exclusive lock on the file. if it succeeds, delete it.
<heftig>
(other programs should keep a shared lock on the file as long as they're interested in it)
<Xzyx987X>
is there a way I can run a code on exit without putting it at the end of the script though? this code is for a library, it is not a script unto itself
<Xzyx987X>
I don't want to add an annoying extra call at the end of every script as a requirement for using the library
<Xzyx987X>
if it comes to that, I could just add something that prunes dead locks when the script gets opened
<bnagy>
libraries shouldn't try to do finalizers etc imho
<Xzyx987X>
it's better than nothing I guess
<bnagy>
just have a #destroy method or whatever
<Xzyx987X>
how would said method get called?
<bnagy>
if you really, srsly, can't make your methods self contained and nonleaky
<bnagy>
leaky_obj.destroy
<heftig>
clean up locks in "ensure" blocks
<Xzyx987X>
so how do I call that when the application exits, including if that exit was triggered by an exception?
<bnagy>
that's what I'm saying - don't do that
<heftig>
what?
<heftig>
it wouldn't violate self-containment
<bnagy>
at_exit in libraries is ugly, and ime not reliable
<heftig>
i'm not talking about at_exit or finalizers
<heftig>
just ensure
<bnagy>
oh, I completely agree with that
<bnagy>
methods should be self-contained and nonleaky
<Xzyx987X>
like I said, I think just cleaning up the locks when the script is loaded is the only thing that will work if I don't have a delete on close flag for opening files
<Xzyx987X>
at least the only thing that is 100% foolproof
<bnagy>
Xzyx987X: heftig said before - if you unlink it right away it will vanish when the last process holding a handle goes away
<Xzyx987X>
oh, really? sorry, must've missed that part
<bnagy>
I don't know how portable that is btw but it will work for all *nix
<heftig>
er, well, it will vanish from the FS right away, but it won't be deallocated until it's closed
<Xzyx987X>
oh, I need it to stay on the fs
<heftig>
so this is definitely the wrong approach
<bnagy>
well I think using the filesystem at all is almost certainly wrong :/
<Xzyx987X>
yea, but given the restrictions I mentioned, what other options do I have?
<Xzyx987X>
I couldn't think of any
<bnagy>
well I don't know enough about your problem
<Xzyx987X>
I'm not saying there aren't any, but off the top of my head, I don't know
<bnagy>
10:20 < heftig> where does that object come from? if it's from a database, use the database's locking mechanisms
<heftig>
also, there's Mutex, which is for multithread synchronization
<heftig>
don't know if it works across forks
<Xzyx987X>
it is either a file, or an object in memory. one of the two, but it can be either
<Xzyx987X>
I need to be able to lock the id of the object in a way that will be consistant across processes
<Xzyx987X>
that's more or less it
<heftig>
IDs are not consistent across processes
<Xzyx987X>
the id is not a ruby id. it is a unique id I create
<bnagy>
it really sounds like you should be using a db for this
<heftig>
then you'd end up with lock rows instead of lock files
<bnagy>
or at least a process that does the object management
<Xzyx987X>
not an option because the code is part of a library. I can't depend on the user setting up a db just for one include
<bnagy>
roll your own then, have an object manager process which exposes an api over drb or whatever
<bnagy>
what are you using multiple processes for, in the first place?
<Xzyx987X>
it's part of a library for ruby cgi scripts to store data in a simple way using the file system that doesn't require you to set up a database, but gives you basic database like functionality
<bnagy>
:|
<Xzyx987X>
it's basically a way to avoid using a database if you either don't have the option of running one, or you don't want to take the trouble
<Xzyx987X>
it obviously won't perform as well, but it is mainly targeted for a smaller site
<Xzyx987X>
it's also fully object based from the ground up, which is nice
tridge has joined #ruby-lang
<Xzyx987X>
well, you know, I actually just though of a way I could get around having to keep memory locks consistent across processes, so I'm just going to do that, and then I can just lock the actual files containing the data
<Xzyx987X>
in other words, never mind :P
jakko_ has joined #ruby-lang
<bnagy>
have you seen pstore?
jfelchner has joined #ruby-lang
<Xzyx987X>
please don't tell me there is already something that does this. lol, my code is practically finished except the lock part.
<Xzyx987X>
well ok, I guess the idea is somewhat similar, what I am doing is much more robust
<bnagy>
no, a real ORM is robust
<bnagy>
what you are doing is a hack :)
<bnagy>
I doubt pstore will work across processes anyway
<Xzyx987X>
fair enough, but it is a useful hack. at least in my opinion
tridge has quit [#ruby-lang]
<Xzyx987X>
actually, as my platform is flexible enough that I could code a few extra classes to make it act as a frontend for an actual database
<Xzyx987X>
that way you could effectively use the same code for storing stuff on a database as stuff on the file system
<Xzyx987X>
so it you for instance had to test some code on a machine where a database was set up, you'd be covered
<Xzyx987X>
*wasn't I mean
<bnagy>
well if it's exactly the same code then you're going to get FS-level locking and performance out of a DB
<bnagy>
which probably isn't what most people would expect
<Xzyx987X>
no, the locking is handled by the device that does the locking
<Xzyx987X>
in this case the database is the device
<Xzyx987X>
that's how the code is set up
<bnagy>
ok well good luck
<Xzyx987X>
thanks, I'll need it...
gregmore_ has joined #ruby-lang
gix has joined #ruby-lang
<zenspider>
Xzyx987X: you can rename the file
chimkan_ has joined #ruby-lang
peppyheppy has joined #ruby-lang
gnufied has joined #ruby-lang
jakko_ has joined #ruby-lang
aran418 has quit ["go team /leave!"]
qpingu has joined #ruby-lang
jakko has joined #ruby-lang
elalande has joined #ruby-lang
crankharder has joined #ruby-lang
srbaker has joined #ruby-lang
rking_ has joined #ruby-lang
fattastic has joined #ruby-lang
rking_ has quit [#ruby-lang]
TTilus has joined #ruby-lang
rippa has joined #ruby-lang
chimkan_ has joined #ruby-lang
kiddorails has joined #ruby-lang
kiddorails has quit [#ruby-lang]
tonesfrommars has joined #ruby-lang
mikeric has joined #ruby-lang
rking_ has joined #ruby-lang
brianpWins has joined #ruby-lang
morozovm has joined #ruby-lang
jakko has joined #ruby-lang
wmoxam has joined #ruby-lang
vesan_ has joined #ruby-lang
gsav has joined #ruby-lang
alexh_ has joined #ruby-lang
alexh_ has quit [#ruby-lang]
jakko has joined #ruby-lang
jakko_ has joined #ruby-lang
Radium has joined #ruby-lang
Oloryn_lt1 has joined #ruby-lang
Swimming_Bird has joined #ruby-lang
mikeric has joined #ruby-lang
nahhh has joined #ruby-lang
x0F_ has joined #ruby-lang
jarred has joined #ruby-lang
jstr has joined #ruby-lang
jfelchner has joined #ruby-lang
jakko has joined #ruby-lang
deobald has joined #ruby-lang
gsav has joined #ruby-lang
gnufied has joined #ruby-lang
yxhuvud has joined #ruby-lang
nofxx has joined #ruby-lang
brushbox has joined #ruby-lang
deobald has joined #ruby-lang
Cope has joined #ruby-lang
<Cope>
hi
<Cope>
given an array like this [['name', 'fred'], ['age', 12], ['eyes', 'blue']]
<Cope>
what's a nice elegant way to convert that into a hash of form name => fredm age => 12, etc
<bnagy>
Hash[*[an_ary]]
Joeysomo has joined #ruby-lang
<Cope>
right... i have this: options = {}; o.each {|i| options[i.first.to_sym] = i.last} - was looking for something nicer
drumond19 has joined #ruby-lang
<Cope>
i wonder if what i have is more readable, if less elagnt
<bnagy>
what's not readable? Hash#[] is not obscure, it exists for the sole purpose of working with two-element arrays like that
<bnagy>
but it won't convert your keys to symbols, you'd need to map first for that
* Cope
nods
<bnagy>
which means something like Hash[*[a.map{|e| [e.first.to_sym,e.last]}]] which is getting pretty ugly