<nakilon>
is stopped working after I specified the branch
TCZ has joined #ruby
postmodern has quit [Quit: Leaving]
schne1der has joined #ruby
<nakilon>
updating gem bundler didn't help
<nakilon>
when I put a breakpoint in bundler to see why it raises the error, it's "def allow_git_ops? ; @allow_remote || @allow_cached ; end" -- both booleans are false for some reason
<nakilon>
nope, they are false too even with master branch so that's not the cause
<nakilon>
this exception seem to be raised many times during bundle exec but handled somewhere
jenrzzz has joined #ruby
jenrzzz has quit [Ping timeout: 256 seconds]
dfucci has joined #ruby
akem has quit [Remote host closed the connection]
alexherbo2 has quit [Ping timeout: 256 seconds]
alexherbo2 has joined #ruby
ruurd has quit [Remote host closed the connection]
iNs has quit [Ping timeout: 240 seconds]
rann is now known as list
iNs has joined #ruby
list is now known as rann
bmurt has joined #ruby
ruurd has joined #ruby
chalkmonster has quit [Quit: WeeChat 2.9]
bmurt has quit [Client Quit]
<nakilon>
so looks like the :branch just does not work in the Gemfile when developing a gem and there is no fix
phage has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nakilon>
have to resolve dependencies as remote master branch but use local copy of custom branch with -I flag; and it would not even work if the branch had other dependencies versions
<nakilon>
consecutive "bundle install" also behaves differently on master and custom branch -- when generating the Gemfile.lock the first time for master it only fetches the code once
<nakilon>
with custom branch it fetches the code from github again and again -- seems like it just can't find the checkouted code
<nakilon>
folders with master HEAD and custom branch HEAD are both fetched: ferrum-3d5f991a92b1/ ferrum-b54cc48250a6/
<nakilon>
hah! changed the "branch: 'false'" to "ref: 'b54cc48250a6'" and it works now
elcuervo has quit [Read error: Connection reset by peer]
elcuervo has joined #ruby
sol1d has quit [Ping timeout: 256 seconds]
<TzilTzal>
Hi.
<TzilTzal>
How can I make a block/lambda be evaluated in the context of the yield-er? I'd like to send a block (from main) to be evaluated inside Class.new but when I yield it, self = main....
akemhp has joined #ruby
<adam12>
TzilTzal: maybe instance_exec or class_exec?
<adam12>
TzilTzal: I'd have to see code to say anything more.
jenrzzz has joined #ruby
jenrzzz has quit [Ping timeout: 260 seconds]
skape has joined #ruby
dionysus69 has quit [Ping timeout: 240 seconds]
jenrzzz has joined #ruby
gray-_-wolf has quit [Quit: WeeChat 2.9]
jenrzzz has quit [Ping timeout: 240 seconds]
Rudd0 has joined #ruby
<TzilTzal>
adam12: I'd like to do:
<TzilTzal>
def foo
<TzilTzal>
...
<TzilTzal>
Class.new(model_klass) do
<TzilTzal>
yield if block_given?
<TzilTzal>
end
<TzilTzal>
end
<TzilTzal>
foo do
<TzilTzal>
belongs_to ....
<TzilTzal>
... more rails model stuff...
<TzilTzal>
end
alfiemax has quit [Remote host closed the connection]
Guest62283 has quit [Remote host closed the connection]
<adam12>
TzilTzal: Maybe a few different ways to do this, but I'd probably capture the block by name, assign the new class to an instance variable, then call instance_exec on that variable with your block as an argument.
<TzilTzal>
The thing is that when currently the block is executed, self = main and therefore blongs_to fails immediately. It's not executed in the context of the newly created class...
<TzilTzal>
adam12: will try your suggestion though.
<adam12>
TzilTzal: You might run into an issue where the binding is odd.
<TzilTzal>
adam12: that's pretty much what I'm looking for. What do you mean binding is odd?
<adam12>
TzilTzal: Capturing the block also captures the binding. In some rare scenarios you may need to rebind the block to a new binding.
<adam12>
TzilTzal: Too much to go into here likely.
jintseng has joined #ruby
<TzilTzal>
hmmm sorry, I'm not that advanced in Ruby, so don't now much about binding...
<TzilTzal>
at any rate - thanks for your help!
<adam12>
TzilTzal: Cheers.
TomyWork has quit [Remote host closed the connection]
phage has joined #ruby
mnathani has quit []
jintseng has quit [Ping timeout: 264 seconds]
sol1d has joined #ruby
<apotheon>
TzilTzal: I'm not actually entirely sure what adam12 means about binding, but if I had to guess I think it's a reference to scope -- that is, the block is bound to a particular scope context, including access to its variables and returning to that context.
<apotheon>
That's just a guess without looking into it too much, though.
<apotheon>
The difficulty for me, without looking more closely, is that there are several different uses of the term "binding" in a programming context, and perhaps more than one of them could apply here. I'm pretty sure this isn't a reference to language binding, though, such as a Ruby API wrapper around a C library. My second guess, after scope binding, would be name binding.
jintseng has joined #ruby
jintseng has quit [Ping timeout: 256 seconds]
jintseng has joined #ruby
Twemlow has joined #ruby
orbyt_ has joined #ruby
neshpion has joined #ruby
jintseng has quit [Ping timeout: 256 seconds]
dfucci_ has quit [Ping timeout: 260 seconds]
Rudd0 has quit [Ping timeout: 256 seconds]
dualfade has quit [Ping timeout: 256 seconds]
neshpion has left #ruby ["WeeChat 2.9"]
dualfade has joined #ruby
meinside has quit [Quit: Connection closed for inactivity]
maryo has joined #ruby
_aeris_ has quit [Remote host closed the connection]
_aeris_ has joined #ruby
jenrzzz has joined #ruby
vondruch has quit [Ping timeout: 265 seconds]
jenrzzz has quit [Ping timeout: 258 seconds]
kristian_on_linu has joined #ruby
gix has joined #ruby
bambanx has joined #ruby
TzilTzal has quit [Quit: Leaving.]
rippa has joined #ruby
pwnd_sfw has quit [Remote host closed the connection]
Iarfen has joined #ruby
oneeggeach has joined #ruby
pwnd_sfw has joined #ruby
maryo has quit [Quit: Leaving]
Twemlow has quit [Quit: Twemlow has now left the arena!]
bambanx has quit [Quit: Leaving]
imode has joined #ruby
towo_ has quit [Quit: I am the vanguard of your destruction. This exchange is over.]
towo has joined #ruby
ChmEarl has quit [Quit: Leaving]
powerhouse has quit [Read error: Connection reset by peer]
phage has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lmat has quit [Ping timeout: 258 seconds]
ruurd has quit [Read error: Connection reset by peer]
ruurd has joined #ruby
TCZ has joined #ruby
powerhouse has joined #ruby
akem has joined #ruby
ruurd has quit [Read error: Connection reset by peer]
ruurd has joined #ruby
roshanavand has joined #ruby
va5c0 has joined #ruby
thither has quit [Ping timeout: 260 seconds]
cnsvc has joined #ruby
sunya7a has joined #ruby
va5c0 has quit [Quit: WeeChat 2.9]
thither has joined #ruby
envex has joined #ruby
jmcgnh has quit [Ping timeout: 264 seconds]
va5c0 has joined #ruby
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
va5c0 has quit [Client Quit]
va5c0 has joined #ruby
va5c0 has quit [Client Quit]
ellcs1 has joined #ruby
va5c0 has joined #ruby
ellcs1 has quit [Ping timeout: 260 seconds]
ur5us has joined #ruby
va5c0 has quit [Quit: WeeChat 2.9]
va5c0 has joined #ruby
wildtrees has joined #ruby
akemhp has quit [Quit: Leaving]
va5c0 has quit [Client Quit]
va5c0 has joined #ruby
va5c0 has quit [Client Quit]
akem has quit [Ping timeout: 240 seconds]
wildtrees_ has joined #ruby
wildtrees has quit [Ping timeout: 240 seconds]
wildtrees__ has joined #ruby
lmat has joined #ruby
wildtrees_ has quit [Ping timeout: 240 seconds]
hiroaki has quit [Ping timeout: 265 seconds]
lmat has quit [Ping timeout: 246 seconds]
wildtrees_ has joined #ruby
lmat has joined #ruby
Technodrome has quit [Ping timeout: 260 seconds]
wildtrees__ has quit [Ping timeout: 256 seconds]
TCZ has quit [Quit: Leaving]
alexherbo22 has joined #ruby
hiroaki has joined #ruby
bmurt has joined #ruby
alexherbo2 has quit [Ping timeout: 260 seconds]
alexherbo22 is now known as alexherbo2
wildtrees__ has joined #ruby
wildtrees__ has quit [Remote host closed the connection]
wildtrees_ has quit [Ping timeout: 240 seconds]
wildtrees has joined #ruby
wildtrees has quit [Max SendQ exceeded]
akemhp has joined #ruby
dfucci has joined #ruby
Iarfen has quit [Remote host closed the connection]
schne1der has quit [Ping timeout: 260 seconds]
dfucci has quit [Ping timeout: 258 seconds]
CrazyEddy has quit [Ping timeout: 265 seconds]
oneeggeach has quit [Quit: Leaving...]
bmurt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<xco>
is there a chance i can do this without a cron job?
<havenwood>
xco: yeah, cron is just one tool
<havenwood>
xco: The timers gem is nice, or your approach works
<xco>
havenwood but you meant the only problem with my approach is "time slipping" correct?
<xco>
i don't see how this is possible though 🤔
<xco>
havenwood perhpah i could take the range out of the loop to avoid the slippage?
Rudd0 has quit [Ping timeout: 260 seconds]
<leftylink>
that does not jive with my understanding
<leftylink>
maybe it's easier to understand if we imagine the task takes 3600 seconds, and then think about what effect that would have on what time this runs every day
Caerus has quit [Ping timeout: 258 seconds]
<leftylink>
for such a case, I don't think taking the range out would work. but maybe I misunderstand what taking the range out entails
e2 has quit [Quit: Stable ZNC provider ##bnc4you]
<havenwood>
xco: The slippage is just because the runtime of the command isn't subtracted. If you don't care about that, no worries.
<havenwood>
xco: The timers gem keeps the loop separate from the command, so it doesn't slip.
thither has quit [Ping timeout: 264 seconds]
<havenwood>
xco: If you don't care about the extra time the command takes not being accounted for in the next loop, it's no problem.
<havenwood>
xco: For example, imagine if `# Do something` spins up a separate thread to no block the timer continuing the loop.
kristian_on_linu has quit [Remote host closed the connection]
<havenwood>
xco: If you don't care about it taking a little extra time each time the command is run then no need to concern yourself. It's common though to see folk not account for the time a command runs so it happens a bit later every increment.
<havenwood>
Just something to keep in mind.
e2 has joined #ruby
alexherbo2 has quit [Ping timeout: 258 seconds]
Caerus has joined #ruby
<xco>
havenwood yeah i got that. the intrust it runs takes less that 2microseconds and it's neglible
<havenwood>
xco: It seems you want variance anyways then, so should be fine.
<xco>
havenwood yup exactly :)
<xco>
ok we're good now
<xco>
thanks you havenwood leftylink
helpa-bot has joined #ruby
Caerus has quit [Ping timeout: 246 seconds]
helpa-bot has quit [Remote host closed the connection]
<adam12>
I do very little work inside the timer tho. Most of it calls out to another service (such as Que)
helpa has quit [Remote host closed the connection]
jenrzzz has joined #ruby
helpa-bot has quit [Remote host closed the connection]
helpa has joined #ruby
<xco>
adam12 thanks for sharing though, looking at your implementation
<adam12>
Hard to believe I wrote it ~ 3 years ago. Time flies.
<xco>
adam12 if you're feeling time flies then it's a good thing. it means you're enjoying your life
<adam12>
xco: Yeah :) Also having kids made me perceive time a lot more.
<xco>
there you go ;)
<adam12>
xco: I cheated a bit by wrapping Concurrent, but back then, I think the only reasonable option was Rufus Scheduler and I think it was somewhat unmaintained then. Seemed simple enough to recreate.
<adam12>
Actually there was one by the Heroku guy too..