jetchisel has quit [Quit: Unfortunately time is always against us -- [Morpheus]]
ur5us has joined #ruby
<nakilon>
pandabot: rb '😃'*5678
<nakilon>
ok, none of these bots is listening to me
<nakilon>
don't make me make another one _--
maria_elis has quit [Ping timeout: 252 seconds]
<leftylink>
auth isn't easy. I haven't had the time to set it up yet
<leftylink>
>> 5
<nakilon>
that's not the output I expected ..D
work has quit [Quit: Connection closed for inactivity]
freeworld has joined #ruby
postmodern has joined #ruby
postmodern has quit [Remote host closed the connection]
sgt_chuckles has quit [Remote host closed the connection]
jimeh1 has quit [*.net *.split]
DEac- has quit [*.net *.split]
DEac- has joined #ruby
jimeh1 has joined #ruby
legit has quit [*.net *.split]
Toledo has quit [*.net *.split]
KramerC has quit [*.net *.split]
lzap has quit [*.net *.split]
dka has quit [*.net *.split]
peder has quit [*.net *.split]
mahlon has quit [*.net *.split]
Artea has quit [*.net *.split]
dka has joined #ruby
Toledo has joined #ruby
lzap has joined #ruby
peder has joined #ruby
Artea has joined #ruby
KramerC has joined #ruby
mahlon has joined #ruby
legit has joined #ruby
postmodern has joined #ruby
lunarkitty has quit [Quit: Connection closed for inactivity]
postmodern has quit [Remote host closed the connection]
Milos has quit [*.net *.split]
jtdowney has quit [*.net *.split]
justache has quit [*.net *.split]
ikeaviking has quit [*.net *.split]
miah has quit [*.net *.split]
pandabot has quit [*.net *.split]
eam_ has quit [*.net *.split]
eam has joined #ruby
miah has joined #ruby
ikeaviking has joined #ruby
jtdowney has joined #ruby
Milos has joined #ruby
justache has joined #ruby
valphilnagel has joined #ruby
ur5us has quit [Ping timeout: 256 seconds]
fanhako has joined #ruby
jetchisel has joined #ruby
valphilnagel has quit [Ping timeout: 252 seconds]
valphilnagel has joined #ruby
teclator has joined #ruby
<nakilon>
why does "bundle install" work without Gemfile on macOS but doesn't in Alpine Linux container?
<valphilnagel>
isn't bundle install depending on Gemfile.lock if it is present?
<nakilon>
it is present
<nakilon>
that's why I'm wondering
<nakilon>
$ docker run --rm -ti -w /usr/src/app -v Gemfile.lock:/usr/src/app/Gemfile.lock ruby:2.3-alpine sh
<nakilon>
# bundle install
<nakilon>
Could not locate Gemfile
Oxfuxxx_ has quit [Ping timeout: 245 seconds]
Oxfuxxx has joined #ruby
ferr_ has joined #ruby
fercell has quit [Ping timeout: 245 seconds]
Rounin has joined #ruby
ferr_ is now known as fercell
TomyWork has joined #ruby
<valphilnagel>
$ docker run --rm -ti -w /usr/src/app -v Gemfile.lock:/usr/src/app/Gemfile.lock ruby:2.3-alpine sh --->
<valphilnagel>
isn't '-v' is mount a volume?
<valphilnagel>
you're mounting a file?
<valphilnagel>
does it work like that?
<valphilnagel>
I think correct one should be : $ docker run --rm -ti -w /usr/src/app -v .:/usr/src/app ruby:2.3-alpine sh
<valphilnagel>
You should be able to drop to shell of the docker and ls to check if the Gemfile.lock is there before bundle install
<nakilon>
mounting a file is fine in docker
<valphilnagel>
Oh ok I didn't know that.. then I won't know why already sorry
Oxfuxxx has quit [Ping timeout: 265 seconds]
kiki_lamb has quit [Ping timeout: 240 seconds]
ur5us has joined #ruby
kiki_lamb has joined #ruby
kiki_lamb has quit [Ping timeout: 252 seconds]
roadie has joined #ruby
hololeap_ has quit [Remote host closed the connection]
hololeap has joined #ruby
Oxfuxxx has joined #ruby
kiki_lamb has joined #ruby
kiki_lamb has quit [Ping timeout: 252 seconds]
flooose has joined #ruby
ur5us has quit [Ping timeout: 252 seconds]
valphilnagel has quit [Remote host closed the connection]
valphilnagel has joined #ruby
kiki_lamb has joined #ruby
kiki_lamb has quit [Ping timeout: 265 seconds]
ur5us has joined #ruby
jetchisel has quit [Quit: Unfortunately time is always against us -- [Morpheus]]
Oxfuxxx has quit [Quit: leaving]
Oxfuxxx has joined #ruby
<nakilon>
when YAML::Store reaches some dozens of megabytes it becomes slow like this https://i.imgur.com/j3SbBHG.png and the flattening on this graph is when I cleaned the files
<nakilon>
I want to make a better PStore
___nick___ has joined #ruby
<nakilon>
that instead of reserializing everything would edit only key-value pairs in place
<nakilon>
but I'm sooooo lazy to reinvent the defragmentation
<ccooke>
nakilon: You may be at the point where switching to a different storage format would be better. sqlite, for instance.
kiki_lamb has joined #ruby
ur5us has quit [Quit: Leaving]
kiki_lamb has quit [Ping timeout: 252 seconds]
<nakilon>
ccooke won't sqlite have an overhead?
<nakilon>
I understand that it's a question of scalability but I have no idea where is exactly that "point for switching"
<ccooke>
nakilon: Ideally, the point of switching is when you can predict that the irremovable bottlenecks in your current approach will impact your system's function
<nakilon>
hm, making own fragmented YAML::Store would need making own parser probably; I'm not sure if it's trivial to split the file into items considering all the possible ways Ruby would like to dump the data
<ccooke>
At this point, you have an irremovable bottleneck in your current storage sytem ("Every change needs a full rewrite"). You can do some work on top to patch that - say, cache changes in memory and do writes in a different thread, with a journal file for recent changes
<nakilon>
or I could use JSON with one key-value per line
<ccooke>
yeah. All of those are viable options. You know your data better
<nakilon>
but then the JSON series aren't becoming a Hash automatically to it would need some additional layer
<ccooke>
(The journal approach is one that works if your change volume isn't too high; basically, you write to a journal file immediately and update the data in memory. The main yaml hash stores a generation number, and every change in the journal has an updated generation. Then when the journal gets to a certain size, you write a new yaml file in a thread)
<nakilon>
"You can do some work on top to patch that" -- I could refactor the storage probably but that shifts my focus in the developing of this app from the actual task to messing with storage problem
<ccooke>
yes
<ccooke>
Although - the storage problem *is* a problem with the app
<ccooke>
you've gone past a threshold where your initial design is inadequate, and you need to solve a problem with it.
<ccooke>
that's just as much an issue with the app as any other functionality
<ccooke>
But what I mean is - you can spend some time patching it, and maybe make things better for now. But those patches might not handle further scale well. Or, you can refactor this part and make more fundamental changes that should scale better
<nakilon>
my current solution is that making app once is a month have an amnesia isn't a big deal so I just moved that db away and it started filling it from start
<nakilon>
so I would have a 250mb large chunk one a month