havenwood has quit [Remote host closed the connection]
havenwood has joined #rubinius
havenwood has quit [Remote host closed the connection]
jnh has quit [Quit: Leaving...]
digitalextremist has quit [Quit: demonstrate freedom //]
carlosgaldino has quit [Ping timeout: 272 seconds]
carlosgaldino has joined #rubinius
|jemc| has quit [Ping timeout: 260 seconds]
JohnBat26 has joined #rubinius
Prathamesh has joined #rubinius
Prathamesh has quit [Client Quit]
RageLtMan has quit [Ping timeout: 245 seconds]
coffeejunk has joined #rubinius
noop has joined #rubinius
dimday has quit [Ping timeout: 244 seconds]
dimday has joined #rubinius
elia has joined #rubinius
dimday has quit [Ping timeout: 245 seconds]
flavio has joined #rubinius
flavio has quit [Changing host]
flavio has joined #rubinius
dimday has joined #rubinius
benlovell has joined #rubinius
elia has quit [Read error: Connection reset by peer]
elia has joined #rubinius
_elia has joined #rubinius
elia has quit [Ping timeout: 246 seconds]
Prathamesh has joined #rubinius
<yorickpeterse>
morning
Prathamesh has quit [Ping timeout: 272 seconds]
dimday has quit [Quit: Leaving.]
Prathamesh has joined #rubinius
Prathamesh has quit [Client Quit]
meh` has joined #rubinius
Prathamesh has joined #rubinius
Prathamesh has quit [Client Quit]
_elia has quit [Quit: Computer has gone to sleep.]
max96at|off is now known as max96at
Prathamesh has joined #rubinius
Prathamesh has quit [Client Quit]
elia has joined #rubinius
benlovell has quit [Ping timeout: 240 seconds]
benlovell has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
heftig has quit [Read error: Connection reset by peer]
heftig has joined #rubinius
elia has joined #rubinius
max96at is now known as max96at|off
max96at|off is now known as max96at
benlovell has quit [Ping timeout: 250 seconds]
benlovell has joined #rubinius
elia has quit [Read error: Connection reset by peer]
elia has joined #rubinius
meh` has quit [Ping timeout: 260 seconds]
max96at is now known as max96at|off
<brixen>
yorickpeterse: oh this rabbit hole lol
<brixen>
almost there though
enebo has joined #rubinius
<yorickpeterse>
heh
<yorickpeterse>
Yeah I kinda figured it wasn't really trivial to solve
<cremes>
fork, exec and fork-exec
<cremes>
fun, fun, and double the fun :)
<brixen>
the signature of spawn is so lulz spawn([env,] command... [,options])
<brixen>
there's literally no reason to have an optional argument precede a required one
<cremes>
that’s the ruby we love
saline has quit [Ping timeout: 258 seconds]
saline has joined #rubinius
carlosgaldino has quit [Remote host closed the connection]
carlosgaldino has joined #rubinius
|Blaze| has quit [Ping timeout: 240 seconds]
|jemc| has joined #rubinius
noop has quit [Ping timeout: 244 seconds]
JohnBat26 has quit [Ping timeout: 260 seconds]
havenwood has joined #rubinius
Prathamesh has joined #rubinius
Prathamesh has quit [Read error: Connection reset by peer]
flavio has quit [Quit: WeeChat 0.4.1]
amsi has joined #rubinius
Kerris has quit []
Prathamesh has joined #rubinius
meh` has joined #rubinius
elia has quit [Ping timeout: 272 seconds]
<brixen>
yay, nearly working
<brixen>
can't wait to remove so many of these locks
<brixen>
interesting to contemplate what "eventually consistent" looks like in a single vm process
<yxhuvud>
What guarantees would that require? serializability, linearability or both? I guess you don't have to care about partitions..
<yxhuvud>
.. until you introduce multiple processes :P
Prathamesh has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Prathamesh has joined #rubinius
Prathamesh has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
havenwood has quit [Remote host closed the connection]
havenwood has joined #rubinius
_whitelogger has joined #rubinius
elia has joined #rubinius
noop has joined #rubinius
<brixen>
yxhuvud: well, there are places where we don't and shouldn't make those guarantees for the program
<brixen>
yxhuvud: consider the operation of returning the number of methods in a method table under concurrent modification
<brixen>
also, I have no interest in creating multiple "processes" inside a single OS process
darix has quit [Remote host closed the connection]
<yxhuvud>
good for you and your brain :P
<yxhuvud>
brixen: but yes, there are relaxations that may be more interesting that the full deal
<brixen>
which is of course why CPUs and caches do them :)
<brixen>
yay, exec, fork, system, backtick specs are sane again
<brixen>
let's see about spawn
<brixen>
haven't even started on popen though :(
<brixen>
lol fork
<brixen>
le sigh unix
<yxhuvud>
I always wonder how they ended up with the arguemnt choices for popen
<yxhuvud>
I especially like the spontaneous optional array that can be used instead of the executable
<yxhuvud>
I guess that is an artifact of the underlaying c api, but still
benlovell has quit [Ping timeout: 272 seconds]
havenwood has quit [Remote host closed the connection]
elia has quit [Quit: Computer has gone to sleep.]
<headius>
yxhuvud: I believe it's because the splitting of a command line into individual arguments can be unreliable for complex command lines
<headius>
the underlying C API requires a list of arguments
<yxhuvud>
headius: well, yeah, but it is still a very strange way of achieving that.
<|jemc|>
sometimes it's nice to not have to escape your spaces
<headius>
yeah
<yxhuvud>
also, one thing to consider is that (as bash recently showed us) is that it is unsafe by default.
<headius>
well, there's no way to make spawning a subprocess any safer than the processes you're spawning
<yxhuvud>
well, not passing on the env by default would improve things somewhat.
<yxhuvud>
I suppose it is a tradeoff vs usability though
<headius>
yeah...manually constructing your own env for every spawn would be unpleasant :-)
<yxhuvud>
it is not always you actually need it. often you know what you need anyhow. also you could pass the full env to it if you need to
<headius>
well, you may know what you need and you may not...there's a lot of env vars you don't think about that need to be there, like temp dir locations, home dir, logged in username
<yxhuvud>
true
amsi has quit [Ping timeout: 246 seconds]
elia has joined #rubinius
amsi has joined #rubinius
lbianc has quit [Quit: ChatZilla 0.9.90.1 [Firefox 24.8.0/20140825140210]]
<jnh>
I figure it's important that people be able to build rubinius before you tag 2.3.0 :)
josh-k has joined #rubinius
erdic has quit [Remote host closed the connection]
erdic has joined #rubinius
elia has quit [Quit: Computer has gone to sleep.]
<headius>
mustmodify: I would not consider it safe, no
<headius>
||= is not guaranteed to be atomic, so there's a possibility of two threads getting different lists and populating them separately; also, arrays are not guaranteed thread-safe in JRuby and Rubinius, so the updates are unsafe anyway
<headius>
I would do @list ||= SOME_SOURCE.to_a.freeze
<headius>
regardless of who gets there first the result will be consistent
<headius>
you may want to dup SOME_SOURCE if to_a doesn't return a new array
erdic has quit [Remote host closed the connection]
erdic has joined #rubinius
<|jemc|>
mustmodify: also remember an ivar in the lexical scope of a class definition is the same as the same-named ivar in a singleton method
<|jemc|>
so you can do:
<|jemc|>
class College; @list=[]; attr_reader :list; ... end
<jnh>
why not wrap it in a mutex?
<|jemc|>
so the fact that it has no #initialize to initialize your ivars doesn't mean you can't initialize them
<jnh>
if in doubt, lock it out
<|jemc|>
jnh: if he's just trying to make sure it's initialized before use I would just initialize it in the class definition
<|jemc|>
imo you should avoid locks if there is a lockless solution to your problem
<locks>
:(
<jnh>
hah!
<|jemc|>
locks: no offense, you're just no my favorite tool in the toolbox