2018-05-25 11:06 GMT+02:00 Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @
Pike (-) developers forum <10...@lyskom.lysator.liu.se>:
> The latter. Basically, there is no legitimate reason for pike code to
> trap these signals since there should be nothing pike code can do that
> cause these signals
Documentation of signal
https://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/signal.html
says:
"Although it IS possible to trap SIGBUS, SIGSEGV etc, I advise you not to;
Pike should not receive any such signals, and if it does, it is because of
bugs in the Pike interpreter"
Should
), but then the extra values are filtered out.
That's quite unexpected to have double values when changing SQL
backends. What's the rationale behind the commit?
--
Best Regards
Tomasz Jamroszczak
to proceed
with the change?
--
Best Regards
Tomasz Jamroszczak
g up that
access for you (if you want) after handling this as a PR.
It's in https://github.com/pikelang/Pike/pull/6.
--
Best Regards
Tomasz Jamroszczak
On Tue, 06 Feb 2018 15:18:16 +0100, Tomasz Jamroszczak
<tjamroszc...@opera.com> wrote:
OK, I'll modify the pull request soon after a few more compilations.
The fixup commit is in the pull request.
--
Best Regards
Tomasz Jamroszczak
think the src/global.h should read:
#if defined(USE_JEMALLOC) && defined(HAVE_JEMALLOC_JEMALLOC_H)
--
Best Regards
Tomasz Jamroszczak
malloc on several machines for a few days I can
see 15% - 20% smaller memory footprint at the cost of bigger CPU usage.
But there's a lot of moving parts so these numbers should not be trusted.
I'll have sound numbers in a week.
--
Best Regards
Tomasz Jamroszczak
GDB or https://microsoft.github.io/debug-adapter-protocol/
Best Regards,
Tomasz Jamroszczak
On Thu, 27 Jun 2019 13:58:02 +0200, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se>
wrote:
/paper-hyperscan-a-fast-multi-pattern-regex-matcher-for-modern-cpus/
For modern CPU:s? Looks more like they are targeting a certain 1970:s
On Thu, 27 Jun 2019 15:59:01 +0200, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se>
wrote:
So I interpret this as "ure3" (whatever that is) being the thing we
actually want, not this garbage fire?
On
On Thu, 27 Jun 2019 17:39:01 +0200, Marcus Comstedt (ACROSS) (Hail
Ilpalazzo!) @ Pike (-) developers forum <10...@lyskom.lysator.liu.se>
wrote:
You can still want things which do not exist. :-) But given the
attitude of the author I don't expect I'll be wanting either that or
hyperscan.
the right way and the lib boasts a lot of optimizations and
speedup. Is there a plan to import the lib to Pike? Would it be easy and
straight-forward to do so?
Best Regards,
Tomasz Jamroszczak
--
Using Opera's mail client: http://www.opera.com/mail/
On Thu, 27 Jun 2019 11:35:04 +0200, Stephen R. van den Berg
wrote:
Tomasz Jamroszczak wrote:
There's the https://github.com/intel/hyperscan regexp library
created over 10 years by algorithm start-up
https://branchfree.org/2019/02/28/paper-hyperscan-a-fast-multi-pattern-regex-matcher
There's no System.Tiem in the documentation. I can access it via Google
Search cache:
https://webcache.googleusercontent.com/search?q=cache:5nqNuHyJgzAJ:https://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/System/Time.html+=1=en=clnk=pl=opera
Best Regards,
Tomasz Jamroszczak
There's no September on
https://lists.lysator.liu.se/pipermail/pike-devel/.
Best Regards,
Tomasz Jamroszczak
it returns HTTP 404.
Best Regards,
Tomasz Jamroszczak
ut(start, 0.0);
return -1;
}
Is there a fix in younger version of Pike?
Best Regards,
Tomasz Jamroszczak
18 matches
Mail list logo
