IRC logs for #farmOS, 2020-12-20 (GMT)

2020-12-19
2020-12-21
TimeNickMessage
[00:16:13]<symbioquine[m]>Ignoring the question of whether it's worthwhile to implement support for complex queries like these, I'd welcome any feedback about whether there's a better way to do this; https://github.com/symbioquine/farmOS_wfs/blob/7.x-1.x/docs/translating_...
[09:37:56]* margoaron has joined #farmos
[09:41:28]* _margoaron has joined #farmos
[09:42:49]* margoaron has quit (Ping timeout: 264 seconds)
[11:08:35]<symbioquine[m]><mstenta[m] "symbioquine: XDebug ALSO updated"> Do you still have a link for these environment var changes handy? I seem to remember XDebug just kind of working for me in the past...
[11:09:04]<mstenta[m]>yes! one sec...
[11:09:32]<symbioquine[m]>No rush :)
[11:09:38]<mstenta[m]>https://github.com/farmOS/farmOS/blob/32effe4dc6a1a37ad37df8c27d865f374f...
[11:09:49]<mstenta[m]>i updated the dev docker-compose.yml template to include them
[11:09:51]<mstenta[m]>and the docs:
[11:10:06]<mstenta[m]>https://2x.farmos.org/development/environment/debug/
[11:10:45]<mstenta[m]>and here's the diff: https://github.com/farmOS/farmOS/commit/9bb7d4f8557f1be29e3664831c236d5c...
[11:11:09]<mstenta[m]>took some fiddling to figure it out, but i think it makes sense... lemme know if you have trouble
[11:11:41]<symbioquine[m]>Should I infer that those changes aren't expected to be needed with the 7.x-1.x devel image?
[11:11:44]<mstenta[m]>(the one that's easy to miss is `remote_host` is now `client` inside the `XDEBUG_CONFIG` env var)
[11:12:03]<mstenta[m]>correct - at least i think that's true... i think we only updated in the 2.x image
[11:13:00]<symbioquine[m]>I seem to remember Eclipse just kind of auto-magically connecting to XDebug - even though I wasn't using it. Now I'm trying to use it, I can't seem to get that to happen... grrr :)
[11:13:11]<symbioquine[m]>I'll check the IP thing.
[11:15:23]<mstenta[m]>yea it was frustrating to get it working again for me
[11:15:33]<mstenta[m]>check your xdebug version to see if you're on 2/3
[11:15:48]<mstenta[m]>they also changed the default port from 9000 to 9003 (eye roll emoji)
[11:18:54]<mstenta[m]>I use PHPStorm, and they published a blog post about the change, which was helpful
[11:18:56]<mstenta[m]>https://blog.jetbrains.com/phpstorm/2020/11/phpstorm-2020-3-eap-6/
[11:19:09]<mstenta[m]>PHPStorm listens on both 9000 and 9003 by default now
[11:19:17]<symbioquine[m]>ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/GDrOUiLxIuzmbKEo... >
[11:19:48]<mstenta[m]>oh dang. that's 7.x-1.x image?
[11:19:51]<mstenta[m]>:-(
[11:20:09]<mstenta[m]>wonder if we can just pin it to v2
[11:20:48]<mstenta[m]>https://github.com/farmOS/farmOS/blob/42a8a730ad242c62a40095a011318c5c2a...
[11:20:55]<symbioquine[m]><mstenta[m] "oh dang. that's 7.x-1.x image?"> Yes, the only special thing is I'm using a version I built including https://github.com/farmOS/farmOS/pull/385
[11:21:27]<mstenta[m]>yea - makes sense that it would be using xdebug 3 now too... we're basically just doing `pecl install xdebug`
[11:21:46]<mstenta[m]>this was a pretty disruptive change IMO
[11:22:17]<mstenta[m]>(@paul121 said he saw a lot of stackoverflow posts flooded in when they did it too - so we're not alone)
[11:22:35]<symbioquine[m]>I think we just need to change that to something like `pecl install xdebug-2.9.8`...
[11:22:50]<symbioquine[m]>I'll try it...
[11:23:24]<mstenta[m]>awesome - yea i say we just pin 7.x-1.x on xdebug 2 and move forward with xdebug 3 for 2.x
[11:24:04]<symbioquine[m]>As long as there aren't too glaring of security problems I suppose
[11:26:22]<mstenta[m]>yea
[11:26:35]<mstenta[m]>although if it's just in the dev image that's not too critical
[11:29:39]<symbioquine[m]>ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/hePlDejyrwEMXIVc... >
[11:29:44]<symbioquine[m]>I'll send a PR...
[11:29:52]<mstenta[m]>woo hoo!
[11:29:56]<mstenta[m]>thanks symbioquine
[11:30:07]<symbioquine[m]>Well I haven't tested that it fixed XDebug for me yet... I guess I should do that too...
[11:30:23]<symbioquine[m]>it did
[11:30:29]<mstenta[m]>huzzah!
[11:32:13]<mstenta[m]>> Ignoring the question of whether it's worthwhile to implement support for complex queries like these, I'd welcome any feedback about whether there's a better way to do this; https://github.com/symbioquine/farmOS_wfs/blob/7.x-1.x/docs/translating_...
[11:32:13]<mstenta[m]>PS this is awesome!!
[11:32:24]<mstenta[m]>Using EntityFieldQuery makes sense to me!
[11:32:29]<symbioquine[m]>Thanks!
[11:33:05]<mstenta[m]>And with regard to 2.x... EntityFieldQuery goes away... but the native entity API is basically the same thing - and even better IMO
[11:33:24]<mstenta[m]>EntityFieldQuery in D7 was sort of a bolt-on after thought
[11:33:34]<symbioquine[m]>I was figuring it would be something like that.
[11:33:50]<symbioquine[m]>Needs to be something filling that niche.
[11:34:07]<mstenta[m]>yea - and i'd be happy to help translate these with you for 2.
[11:34:10]<mstenta[m]> * yea - and i'd be happy to help translate these with you for 2.x
[11:35:05]<mstenta[m]>i'm working on the asset location logic right now in my `2.x-location` branch - coming along nicely!
[11:35:24]<symbioquine[m]>yay!
[11:38:49]<symbioquine[m]>https://github.com/farmOS/farmOS/pull/391
[11:41:05]<mstenta[m]>symbioquine: Drupal 9 uses Symfony's service container, which could be a really nice way for us to have "swappable" geometry logic - to leverage PostGIS if/when it's available
[11:42:23]<mstenta[m]>eg: i could imagine a service (which is just a class w/ interface) that has the `EntityFieldQuery` code you're working on
[11:42:49]<mstenta[m]>and a `postgis` module that, if enabled (only if you have postgis), replaces the service class with another one, which uses direct postgis queries instead
[11:43:03]<symbioquine[m]>Yeah, makes sense
[11:43:05]<mstenta[m]>(maybe just one way of doing it... probably others)
[11:43:37]<mstenta[m]>i'm basically going to use that approach with the "Group" logic
[11:43:54]<mstenta[m]>eg: we'll have an `asset.location` service for getting an asset's current location/geometry
[11:44:14]<mstenta[m]>and if the `group` module is enabled, it will replace the class with one of it's own, which also takes into account asset group membership
[11:44:30]<mstenta[m]>(that's the current thought anyway - i think it will work)
[11:45:10]<symbioquine[m]>It's a decorator I assume?
[11:45:36]<symbioquine[m]>i.e. checks for a "group location" and if there isn't one, it delegates to the original location service?
[11:45:58]<mstenta[m]>yup!
[11:46:03]<symbioquine[m]>cool!
[11:46:05]<mstenta[m]>in theory :-)
[11:46:38]<mstenta[m]>this will solve the weird conundrum we have right now where an asset can have movements, and also be in a group with movements (where is the asset??)
[11:47:10]<mstenta[m]>the thought is: it will basically include the group's movement logs, so whichever one is the "latest" will take precedence in determining location
[11:47:25]<mstenta[m]>so you could still move an asset separately from a group, while still being part of the group
[11:47:43]<mstenta[m]>(eg: if a cow gets sick and moves to quarantine or something, but is still a member of the herd)
[11:47:45]<symbioquine[m]>ah, yeah that would get a bit tricky to do in the decorator pattern.
[11:48:06]<mstenta[m]>mm yea... might need to think it through some more... getting there :-)
[11:48:35]<mstenta[m]>the location stuff i'm working on now is the bulk of the work... hopefully adding the group logic next will be easier
[11:48:37]<symbioquine[m]>Maybe instead of the service being a "location service" it's a movement history service?
[11:49:02]<symbioquine[m]>So the decorator can modify the query results to add it's own history events...
[11:49:16]<mstenta[m]>ah hmm yea that's an idea
[11:50:15]<mstenta[m]>actually that's not too far off from what i have
[11:50:23]<symbioquine[m]>nice
[11:50:24]<mstenta[m]>i actually have a location service and a general purpose log query service
[11:50:46]<mstenta[m]>(location service is ALSO used for "fixed" assets, so movements aren't always part of that logic)
[11:52:21]<mstenta[m]>and so: yea... maybe the log query service (or an extension of it) can become a more general purpose "movement history service" in that regard too
[11:52:37]<mstenta[m]>which the location service uses
[11:52:54]<symbioquine[m]>yeah
[11:54:00]<mstenta[m]>(the log query service is a little more specific than just a service for loading logs... it is sort of specific to farmOS's model of "finding latest log that references an asset at a particular time")
[11:54:13]<mstenta[m]>this is what it looks like to "find the latest movement log":
[11:55:02]<mstenta[m]>ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/SAiddKiULBAxmalk... >
[11:55:44]<mstenta[m]>(the `$options` array is just a helper that gets parsed by `getQuery()` to add standard conditions)
[11:55:58]<mstenta[m]>similar to `farm_log_query()` in 1.x
[14:12:10]<mstenta[m]>Huzzah! My asset location tests are passing :-)
[14:12:46]<mstenta[m]>(still more to do... but it's working!)
[15:43:06]* _margoaron has quit (Ping timeout: 265 seconds)
[16:05:35]* margoaron has joined #farmos
[16:36:50]* cpm has quit (Quit: Leaving)