Really looking forward to using this. It's the type of easily overlooked
feature that can turn out to be a huge time saver if the developer/platform
maintainer is aware of it!
---
Reply to this email directly or view it on GitHub:
with the flag DBG_LOCK set(from menuconfig for example), with each
lock will be stored information regarding the place from where the
lock was aquired (file, function, line)
You can view, comment on, or merge this pull request online at:
https://github.com/OpenSIPS/opensips/pull/621
-- Commit
Branch: refs/heads/master
Home: https://github.com/OpenSIPS/opensips
Commit: 5e19a946d456641eaaddac9528323f272fd81986
https://github.com/OpenSIPS/opensips/commit/5e19a946d456641eaaddac9528323f272fd81986
Author: Razvan Crainea raz...@opensips.org
Date: 2015-08-27 (Thu, 27 Aug
Branch: refs/heads/2.1
Home: https://github.com/OpenSIPS/opensips
Commit: 31a3132297f1a65f211e9f54951b4d7cda0084c9
https://github.com/OpenSIPS/opensips/commit/31a3132297f1a65f211e9f54951b4d7cda0084c9
Author: Razvan Crainea raz...@opensips.org
Date: 2015-08-27 (Thu, 27 Aug
Branch: refs/heads/2.1
Home: https://github.com/OpenSIPS/opensips
Commit: 4586ffceb56bcdd3b075dd9660b83537fe32313a
https://github.com/OpenSIPS/opensips/commit/4586ffceb56bcdd3b075dd9660b83537fe32313a
Author: Bogdan-Andrei Iancu bog...@opensips.org
Date: 2015-08-27 (Thu, 27 Aug
@qmphan , you are right! The only issue I see with that approach is that we
will break many other modules. Most of them do expect to get a DB_STRING after
a DB query - and they actually check the DB type. If we change to DB_STR, all
these modules will get broken.
What can be done is to :
1)
Branch: refs/tags/2.1.1
Home: https://github.com/OpenSIPS/opensips
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Branch: refs/tags/2.1
Home: https://github.com/OpenSIPS/opensips
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Branch: refs/heads/master
Home: https://github.com/OpenSIPS/opensips
Commit: d3aaf44ccca7eadd0a58914ec54b1ddf17972c46
https://github.com/OpenSIPS/opensips/commit/d3aaf44ccca7eadd0a58914ec54b1ddf17972c46
Author: Bogdan-Andrei Iancu bog...@opensips.org
Date: 2015-08-27 (Thu, 27
Yeah, that's the safest way! I didn't see that there are checks for DB_STRING
type in other modules.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/619#issuecomment-135464027___
Devel mailing list
You can view, comment on, or merge this pull request online at:
https://github.com/OpenSIPS/opensips/pull/622
-- Commit Summary --
* revert recent changes in dialog module because they were not optimal. A
better fix is to populate the field .len for DB_STRING in db_postgres module
*
Branch: refs/heads/1.8
Home: https://github.com/OpenSIPS/opensips
Commit: 62fda14b20ad929e580680efef65bcde2a713326
https://github.com/OpenSIPS/opensips/commit/62fda14b20ad929e580680efef65bcde2a713326
Author: Bogdan-Andrei Iancu bog...@opensips.org
Date: 2015-08-27 (Thu, 27 Aug
Closed #619.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/619#event-393831928___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
@bogdan-iancu: Would the use of DB_STR type and VAL_STR(...).len resolve the
problem?
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/619#issuecomment-135368703___
Devel mailing list
Branch: refs/heads/master
Home: https://github.com/OpenSIPS/opensips
Commit: d12e8778d27b81f1e75574275c61b9bd975dc9c7
https://github.com/OpenSIPS/opensips/commit/d12e8778d27b81f1e75574275c61b9bd975dc9c7
Author: Eseanu Marius Cristian eseanu.crist...@gmail.com
Date: 2015-08-25
Merged #620.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/620#event-393838156___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Branch: refs/heads/master
Home: https://github.com/OpenSIPS/opensips
Commit: 3cb77f9a722ec7ea310ebe9ecd87c00b02f18410
https://github.com/OpenSIPS/opensips/commit/3cb77f9a722ec7ea310ebe9ecd87c00b02f18410
Author: Bogdan-Andrei Iancu bog...@opensips.org
Date: 2015-08-27 (Thu, 27
Yes, I do know. AFAIK the travis containers run only these jobs, so it there
are no other processes affected.
---
Reply to this email directly or view it on GitHub:
Not really, as the the .len (for DB_STR) is not populated by the db_postgres
driver.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/619#issuecomment-135372459___
Devel mailing list
Branch: refs/heads/master
Home: https://github.com/OpenSIPS/opensips
Commit: 1fac483965c4b0fa56e1fea607c53bf7971760c5
https://github.com/OpenSIPS/opensips/commit/1fac483965c4b0fa56e1fea607c53bf7971760c5
Author: Razvan Crainea raz...@opensips.org
Date: 2015-08-27 (Thu, 27 Aug
When values are read from DB, they are converted to C structures by going
through these functions:
db_postgres_fetch_result -- db_postgres_convert_rows --
db_postgres_convert_rows -- db_postgres_str2val
Inside the last function (db_postgres_str2val), if the DB type is DB_STR, the
len field
If you pull in the #618, db_postgres driver will populate the .len ;)
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/619#issuecomment-135373488___
Devel mailing list
Devel@lists.opensips.org
Maybe I'm missing something, but that PR changes only the type of the column
from STRING to STR, but the actual value returned in res is the
samewithout the .len filled in.
---
Reply to this email directly or view it on GitHub:
Added required dependencies in order to load clusterer api correctly.
You can view, comment on, or merge this pull request online at:
https://github.com/OpenSIPS/opensips/pull/620
-- Commit Summary --
* clusterer: added dependencies
* clusterer: changed default name for a column
*
Branch: refs/heads/master
Home: https://github.com/OpenSIPS/opensips
Commit: 4a240df659e698556ada2688bbfe6bda253b5493
https://github.com/OpenSIPS/opensips/commit/4a240df659e698556ada2688bbfe6bda253b5493
Author: Razvan Crainea raz...@opensips.org
Date: 2015-08-27 (Thu, 27 Aug
Branch: refs/heads/master
Home: https://github.com/OpenSIPS/opensips
Commit: f5850238d4f1e7d09c9e803480284aa94827ed8f
https://github.com/OpenSIPS/opensips/commit/f5850238d4f1e7d09c9e803480284aa94827ed8f
Author: Razvan Crainea raz...@opensips.org
Date: 2015-08-27 (Thu, 27 Aug
I tried to install the module command but still can't replicate this behavior.
Can you check whether the latest code (2.1.1) still has this problem?
---
Reply to this email directly or view it on GitHub:
You do know that `-j` does not restrict the number of processes?
```
-j [jobs], --jobs[=jobs]
Specifies the number of jobs (commands) to run simultaneously.
If there is more than
one -j option, the last one is effective. If the -j option is
given without an
28 matches
Mail list logo
