Github user SolidWallOfCode commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219107725
The recipe in `docs/developer/config-vars.en.rst` needs to be updated for
this new structure.
---
If your project is set up for it, you can reply to this
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219104889
Well, static / no-static, it still needs a container from lib/ts.
---
If your project is set up for it, you can reply to this email and have your
reply appear on Gi
Github user jpeach commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/634#discussion_r63218410
--- Diff: proxy/InkAPI.cc ---
@@ -8175,471 +8177,163 @@ TSHttpTxnConfigStringGet(TSHttpTxn txnp,
TSOverridableConfigKey conf, const char
return T
Github user jpeach commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/634#discussion_r63218243
--- Diff: proxy/InkAPI.cc ---
@@ -8175,471 +8177,163 @@ TSHttpTxnConfigStringGet(TSHttpTxn txnp,
TSOverridableConfigKey conf, const char
return T
Github user SolidWallOfCode commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/634#discussion_r63216314
--- Diff: proxy/InkAPI.cc ---
@@ -8175,471 +8177,163 @@ TSHttpTxnConfigStringGet(TSHttpTxn txnp,
TSOverridableConfigKey conf, const char
Github user jpeach commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/634#discussion_r63216086
--- Diff: proxy/InkAPI.cc ---
@@ -8175,471 +8177,163 @@ TSHttpTxnConfigStringGet(TSHttpTxn txnp,
TSOverridableConfigKey conf, const char
return T
Github user jpeach commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/634#discussion_r63216041
--- Diff: proxy/InkAPI.cc ---
@@ -8175,471 +8177,163 @@ TSHttpTxnConfigStringGet(TSHttpTxn txnp,
TSOverridableConfigKey conf, const char
return T
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219098651
Basically anything that is in trafficserver which would be considered the
critical path. The big exception here are plug-ins, because in many cases there
is no bett
Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219077066
That seems like something we should include in some sort of "contributor"
documentation in the root of the repo :)
---
If your project is set up for it, you ca
Github user sudheerv commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219075656
Just fyi -
https://mail-archives.apache.org/mod_mbox/trafficserver-dev/201507.mbox/%3CA16410D3-9E7B-4042-A819-F361BFD5002C%40apache.org%3E
---
If your
Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219075424
@SolidWallOfCode Seems like you are the keeper of the maps-- do you have
docs or examples I can follow to use different maps?
---
If your project is set up for
Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219071582
Okay, I guess I'm misunderstanding what "core" is, that is in proxy (same
dir as this) and its also in "iocore" (which has core right in the name). Where
exactl
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219070850
That is not in the core.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not ha
Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219070741
@zwoop We do have unordered_map in the core
(https://github.com/apache/trafficserver/blob/master/proxy/logstats.cc#L55).
I also guess I don't quite unde
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219068283
No, we do not use unordered_map in our core. Until we decide otherwise (on
mailing lists), no STL in the core. The STL that is in there was put in for no
good reaso
Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219066268
Adding comment from email (apparently Githib's auto-comment email isn't in
our emails to dev@):
We already pull stl in the core in a couple other places
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219063157
[approve ci]
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feat
We already pull stl in the core in a couple other places. And to Brian's
point since this is effectively a constant (never mutates) the allocations
don't matter.
On May 13, 2016 6:21 AM, "zwoop" wrote:
> Github user zwoop commented on the pull request:
>
>
> https://github.com/apache/trafficserve
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-219040807
Sudheer brings up a valid point. We should use the hash tables that we have
in lib/ts for core code.
---
If your project is set up for it, you can reply to this e
Github user bgaff commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-218960894
If you're going to use STL you should probably incorporate the stl
allocators, or if we're going to settle on jemalloc then it doesn't matter
---
If your project i
Github user sudheerv commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-218950857
Are we now okay with letting the use of STL in the core?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub a
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-218946224
[approve ci]
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feat
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-218945356
Yeah, this seems nicer.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not hav
Github user atsci commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-218945321
Yeah, this seems nicer.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not hav
Github user atsci commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-218945006
Test response (manually).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not h
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/634#issuecomment-218944885
Just a test [approve ci]
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not ha
GitHub user jacksontj opened a pull request:
https://github.com/apache/trafficserver/pull/634
TS-4439 Reimplement TSHttpTxnConfigFind
This needs some cleanup (probably better names, and probably should move
the PAIR struct out to the header file), but I want to get some feedback on
27 matches
Mail list logo
