IRC logs for #farmOS, 2016-10-19 (GMT)

2016-10-18
2016-10-20
TimeNickMessage
[20:11:43]* kadaan is now known as kadaan_
[21:26:19]* JustTB has joined #farmos
[21:28:48]* JustTB1 has quit (Ping timeout: 245 seconds)
[01:01:05]* kadaan_ is now known as kadaan
[01:47:40]<kadaan>@mstenta: So far, so good. Though I had to go to http://localhost/install.php?profile=farm to get to the install. The IP address identified by `docker inspect --format '{{ .NetworkSettings.Networks.farmos_default.IPAddress }}' farmos_www_1` timed out.
[01:53:56]<kadaan>It seems as if drush is modifying the farm modules and adding `; Information added by drush on 2016-06-08\nversion = "7.x-1.2+0-dev"\nproject = "farm_access"\ndatestamp = "1465413099"` to all the farm_*.info files. This make it a little bit more of a pain to work with these git repos,
[02:06:07]* kadaan is now known as kadaan_
[02:40:18]* kadaan_ has quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
[04:45:45]* M-DzzzzzzR has quit (Remote host closed the connection)
[04:58:55]* M-DzzzzzzR has joined #farmos
[09:04:04]<mstenta>farmBOT: tell kadaan https://github.com/farmOS/farmOS/issues/18
[09:04:04]<farmBOT>mstenta: I'll pass that on when kadaan is around.
[09:05:23]<mstenta>farmBOT: tell kadaan Regarding the IP address... maybe that command doesn't work in all environments. If you just do "docker inspect farmos_www_1" - you should see the IP address down near the bottom. The --format piece is just a way to try to automatically filter it. But maybe the "NetworkSettings.Networks.farmos_default.IPAddress" path is different in your case? Can you check?
[09:05:23]<farmBOT>mstenta: I'll pass that on when kadaan is around.
[09:51:46]* JustTB has quit (Quit: Leaving.)
[12:05:43]* kadaan has joined #farmos
[12:19:53]<kadaan>Thanks for fixing the info file.
[12:19:53]<farmBOT>kadaan: 3 hours 15 min ago <mstenta> tell kadaan https://github.com/farmOS/farmOS/issues/18
[12:19:53]<farmBOT>kadaan: 3 hours 14 min ago <mstenta> tell kadaan Regarding the IP address... maybe that command doesn't work in all environments. If you just do "docker inspect farmos_www_1" - you should see the IP address down near the bottom. The --format piece is just a way to try to automatically filter it. But maybe the "NetworkSettings.Networks.farmos_default.IPAddress" path is different in your case? Can you check?
[12:20:41]<kadaan>No, IP address is returned correctly, but I cannot use it to connect to the site.
[12:21:00]<mstenta>kadaan: oh
[12:21:01]<mstenta>huh
[12:21:16]<mstenta>does ping work?
[12:26:42]<kadaan>Ping does not work.
[12:27:05]<kadaan>FYI, connecting to the site via localhost works and I'm able to install.
[12:27:34]<kadaan>Which brings me to my other question. How long does the install take for you? For me it seems to be almost 1 hour.
[12:32:59]<kadaan>After that, the site seems to perform about as well as it did when I ran it in docker before.
[12:33:19]<kadaan>Should we include the git versions of components like `log`?
[12:35:55]<mstenta>yea, installation is ungodly slow for me too - i don't know why
[12:36:07]<mstenta>i enabled php's opcache, fyi, but it didn't make a difference
[12:36:12]<mstenta>you're on mac right?
[12:36:20]<mstenta>that's probably why it is slow for you...
[12:36:40]<mstenta>i am using mine inside a truecrypt container - which might explain the slowness for me... i'm going to test it outside of truecrypt
[12:36:51]<mstenta>weird that ping doesn't work, but localhost does
[12:36:55]<mstenta>i guess just use that
[12:37:05]<mstenta>i'm not sure how the networking all works on mac
[12:43:18]<kadaan>Cool.
[12:43:54]<mstenta>so one thing that might be worth trying on mac...
[12:44:04]<mstenta>er, well...
[12:44:05]<mstenta>hmm
[12:44:15]<mstenta>nevermind
[12:44:36]<mstenta>i was gonna say try running the database container without a volume... but i think it's baked into the Dockerfile for mysql
[12:44:45]<mstenta>i have a feeling it's the db container that's slowing you down
[12:45:12]<mstenta>more so than the apache container
[12:45:18]<mstenta>because drupal makes a lot of db calls
[12:45:28]<kadaan>I think it is that fact that the DB container is mapped as a volume.
[12:45:36]<mstenta>yea i do too
[12:45:58]<mstenta>i was gonna say to just comment that out in the docker-compose.yml... but i don't think that will do it
[12:46:11]<mstenta>because the mysql Dockerfile contains a VOLUME command... which means a volume will be created regardless
[12:46:40]<mstenta>i suppose you could build your own mysql image, and remove the VOLUME command
[12:46:54]<mstenta>that's a lot of extra work... but it would be a good way to test whether or not it is the volume
[12:55:53]<kadaan>Either way, you want the volume so that the DB is persisted across rebuilds, right?
[12:56:45]<mstenta>kadaan: well yes...
[12:57:09]<mstenta>but... you could probably get away with only rebuilding the www container, and leaving the mysql container alone
[12:57:15]<mstenta>if it helps to speed things up for you on mac
[12:57:20]<mstenta>again, this would be a workaround
[12:57:33]<mstenta>not something we would do in the official image
[12:57:45]<mstenta>i mean in the official docker-compose.yml
[12:57:56]<mstenta>but yea - if you then destroyed the mysql container, you would lose the database
[12:58:05]<mstenta>but if you're only using it for local development, maybe that's ok
[12:58:18]<mstenta>if it improves the speed
[12:58:22]<mstenta>a lot of "if"s
[12:59:56]<kadaan>hehehe
[13:00:03]<kadaan>I'll have a look later.
[13:00:11]<mstenta>ah ha! i think i solved my slowness issue!
[13:00:23]<mstenta>it was because i was running it from within a truecrypt container
[13:00:25]<kadaan>The other thing I was wondering is if we should include log in the git checkout.
[13:00:28]<mstenta>duh - makes sense :-)
[13:00:33]<kadaan>Totally
[13:00:43]<mstenta>re: log in git checkout... perhaps
[13:01:03]<mstenta>ps: i still need to review your time tracking stuff...
[13:01:10]<mstenta>but it relates to that...
[13:01:44]<mstenta>i think the time tracking data should be stored in Fields on the various log types... but not directly in the {log} table schema
[13:02:04]<mstenta>because the Log module is not specific to farmOS... and time tracking is not a general requirement for it
[13:02:27]<mstenta>ie: Log will be used in Ledger for bookkeeping entries... but you don't need to know how long you spent making a transaction
[13:02:51]<mstenta>so instead, we should add fields to the farmOS log types for tracking time spent
[13:04:34]<kadaan>Ewwwww
[13:04:52]<kadaan>It makes me feel gross to do it that way.
[13:04:58]<mstenta>why?
[13:05:18]<kadaan>Because it is changes in so many places.
[13:05:40]<kadaan>We already have farm_log, but it really isn't just a farm specific extension of log.
[13:05:59]<mstenta>yes, but that is how all other fields work
[13:06:01]<kadaan>A good compromise might be a farm specific version of log that adds time_spent.
[13:06:29]<kadaan>Or add the ability to enable time_spent for a specfic log type
[13:06:43]<kadaan>In the configuration of log.
[13:06:49]<mstenta>enabling time_spent per log type could work
[13:06:57]<mstenta>that could be an add-on module for Log
[13:07:07]<mstenta>with config to define which log types it applies to
[13:07:21]<kadaan>I'm not really sure how to do that.
[13:07:41]<mstenta>it is a bit more involved... but it makes sense if the time tracking needs to become more complicated in the future (and maybe it does)
[13:07:50]<mstenta>i could help spec up what that would look like
[13:08:11]<kadaan>I my ignorance, I would just add a config property (like the one that allows done to be automatically checked) which indicates whether time tracking is enabled.
[13:08:24]<mstenta>but we could also START with individual fields on the log types... and then if/when we make the log_time module (or whatever it is called), we could add an automated update code to migrate the data and remove thoe fields
[13:08:45]<kadaan>We could...
[13:09:09]<mstenta>yes, that's how it would work... but that config would be stored in a different database table than {log_type}... maybe {log_time_type} or something
[13:09:25]<mstenta>(because modules shouldn't modify other module's tables)
[13:09:30]<kadaan>Makes sense.
[13:09:42]<kadaan>I'd rather add the module than modify all the existing modules...
[13:09:53]<kadaan>But either way.
[13:10:02]<mstenta>ok - maybe we could start by specing it out
[13:10:04]<kadaan>I had already done it the first way.
[13:10:10]<kadaan>And really didn't like it.
[13:10:15]<kadaan>That is why I put it in Log.
[13:10:22]<mstenta>yea... :-( sorry i wish i had a chance to jump in before you did
[13:10:40]<kadaan>np
[13:10:47]<kadaan>I greatly prefer it in log.
[13:10:55]<kadaan>So I would greatly prefer it in log_time_tracking.
[13:11:06]<mstenta>ok - yea i think that would be great
[13:11:22]<kadaan>If done that way, making new modules or new log types becomes much easier.
[13:11:29]<mstenta>yes indeed
[13:11:48]<mstenta>brb need some lunch
[13:12:02]<kadaan>Is there an example of how to make a add-on module?
[13:12:03]<kadaan>np
[13:13:53]<mstenta>kadaan: this one wouldn't be too hard, i don't think
[13:14:12]<mstenta>brb
[13:17:53]<kadaan>np
[13:31:35]<mstenta>kadaan: another thought i had re: time tracking...
[13:31:50]<mstenta>we might want more than just the one field
[13:32:05]<mstenta>we might want to be able to have a whole "timesheet" on each log
[13:32:15]<mstenta>that multiple people could punch in/out on
[13:32:45]<mstenta>and it would record multiple sessions of time spent, potentially at different times of day, or different days
[13:33:03]<mstenta>then it could tally those up to give a total amount of time spent on the task... and maybe also how long each person spent on it
[13:33:27]<kadaan>I had thought about that too.
[13:33:32]<kadaan>Easier if it is a new table.
[13:33:35]<mstenta>(combined with a concept of how much each person's time is worth would allow for some pretty good cost calculations for man-hours)
[13:33:40]<mstenta>yea definitely easier
[13:33:53]<kadaan>I like it
[13:33:57]<mstenta>let's start brainstorming some of these things in the time tracking issue on drupal.org
[13:34:02]<mstenta>the one that @brucedawson is in on
[13:34:40]<mstenta>maybe the module could be called "log_timesheet"
[13:34:51]<mstenta>or something... "log_time_tracking" is good too...
[13:35:35]<mstenta>we can throw some ideas around for the name too (without splitting hairs too much - it doesn't matter a whole lot)
[13:36:04]<mstenta>also i'll need to decide if i want to include that module in the http://drupal.org/project/log project itself, or if maybe it should be its own project http://drupal.org/project/log_time_tracking
[13:36:18]<mstenta>i'm leaning towards a separate project... to keep the maintenence of both separate
[13:36:44]<mstenta>and i could make you co-maintainer of it so you could start building up your drupal.org commit counts :-)
[13:40:40]<mstenta>i'm updating the drupal.org issue with some of these thoughts...
[13:42:55]<kadaan>k
[13:43:00]<kadaan>I'll update there when I have tome.
[13:43:02]<kadaan>time
[14:33:13]* kadaan is now known as kadaan_
[15:44:15]* kadaan_ is now known as kadaan
[17:59:32]* kadaan is now known as kadaan_
[18:42:02]* JustTB has joined #farmos
[19:12:53]* Lil has quit ()