Chris Angelico wrote:
>On Fri, 8 Dec 2023 at 19:39, Stephen R. van den Berg wrote:
>Yeah, still unable to get a connection to succeed as of this week's
>latest master. I wanted to compare against Pike 8.0, but the Shuffler
>transformation came in since then, so I wasn't able t
Chris Angelico wrote:
>3. It's surprisingly hard to find tools that can help you debug client
>certificates.
It's a mess. It has been a mess for a long time.
The few times I tried to use something like wireshark or tcpdump to peek
into an SSL connection I gave up after trying for a while. It's
Chris Angelico wrote:
>In working on the implementation, I'm running into some trouble with
>SSL connections in general. As of Pike 8.1, the pgsql module uses
>Shuffler (this wasn't the case in Pike 8.0, but for unrelated reasons
>I'm not able to build Pike 8.0 on here at the moment). Non-SSL
Chris Angelico wrote:
>use_ssl - use SSL if available, else unencrypted
>force_ssl - use SSL or fail if not supported
>ssl_context - if SSL is enabled by either of the above options, use
>this SSL.Context
Sounds good to me.
I see the following changes in pgsql_util.pmod:
957c958
< Thread.MutexKey lock = closemux->lock();
---
> void|Thread.MutexKey lock = closemux->lock();
< private Thread.Queue qportals;
---
> private zero|Thread.Queue qportals;
What is the difference between declaring a
Chris Angelico wrote:
>> > few months. It's not a simple fix. The default behaviour of
>> > Protocols.DNS.async_host_to_ip, which is used by Protocols.HTTP,
>> > changed from "only look up A records" to "look up and A records,
>> > and return the first if found, otherwise the first A".
It's still work in progress, but in case anyone is looking for
something to run devices off and is programmed in Pike.
I bought some equipment from www.hapcan.com and then
programmed a hapcanmonitor daemon.
The system is successfully running my house.
A quick rundown on the source:
-
I'm writing a generic HTTP server and will probably be writing
a full-fledged SMTP server as well (queueing messages in a database,
automatic DKIM signage, full MX-DNS support with retries and
automatic fallback/backoff for recipient servers that don't allow
many recipients or many connections or
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>My testcase works now. Thanks.
You might want to try using the Shufflerised Server.Request mode, simply use:
void httprequest(object request) {
request->set_mode(Protocols.HTTP.Server.Request.SHUFFLER);
...
}
I'm using that in
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>>Ok, lingering callbacks. Squashed.
>Setting the fd to blocking after it has been handed over to the next
>request object makes the subsequent request hang. There is still a bug
It is only set to blocking when it is not being
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>Well, it's closer...
>Bad argument 1 to output_to(). Expected object|function.
>Unknown program: output_to(0)
Ok, lingering callbacks. Squashed.
--
Stephen.
Stephen R. van den Berg wrote:
>>The problem appears to be writes after finished() has been called. As
I think I tried to be a bit too agressive regarding cleaning up memory
too soon. Pushed a fix just now. Please verify that it works now.
--
Stephen.
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>Looks like the Protocols.HTTP.Server is broken, though I don't know
>how recently as it was a while ago I installed the previous Pike
>8.1. It's never the first request that fails, so I'm suspecting
>something like keep-alive, though
Chris Angelico wrote:
>My usual practice is to completely recompile the class, and have a
>single mapping for all "carry-over" state, something like this:
>And then to replace anything, I'd create a new instance of the
>newly-compiled class, replace its empty state mapping with the same
>one as
Lance Dillon wrote:
>The closest I could see is to not really have the functions directly, I guess,
>but an mapping of functions, and overload `() so that it pulls the function
>from the mapping, then you could easily replace the function by replacing the
>reference in the mapping.
>The
Chris Angelico wrote:
>trying to do won't work with injection. But perhaps subclassing can do
>what you want - instead of compiling the entire class again, create a
>subclass that replaces that one function.
Yes, well, that won't cut it, I'm afraid, because I specifically want
that function to be
Say I have this:
class A {
int k;
void B() {
write("foo %d\n", k);
}
void C() {
k = 3;
write("bar\n");
}
}
int main() {
A a = A();
a->C(); // Displays: bar
a->B(); // Displays: foo 3
// At this point I want to replace the function B
// in the
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>>Sql.Promise()
>Thanks. Yes, like that, but non-blocking :) Doesn't look like MySQL is
>using the mysql_*_nonblocking functions.
I see. With PostgreSQL (obviously ;-)) it *is* non-blocking.
Soon (hopefully) I'll have a working CQL
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>Anyone looked at asynchronous database query API? I'm thinking about
>all the big_query, big_typed_query etc. but retuning a Promise.
Sql.Promise()
I've used it in applications.
It works fine, I think.
You want something different?
Any suggestions on how I can find out in this coredump where the
original exception was? (i.e. which pike file and linenumber point
at the spot where we tried to access the variable in the destructed object).
Pike compiled with -O2 -g, no PIKE_DEBUG.
Program terminated with signal SIGABRT,
The current bleeding edge Pike runs again for me. Thanks!
All that's left, are a bunch of warnings:
lib/modules/Standards.pmod/X509.pmod:105: Warning: Illegal to redefine
inherited variable tag with different type.
lib/modules/Standards.pmod/X509.pmod:105: Warning: Expected: int(1..).
Apr 9 19:37:43 2021 +0200
Compiler [Typechecker]: Fix NULL-deref in even_lower_and_pike_types().
The last time I had a bleeding edge "standard" pike that actually
worked for me was:
commit 94a868dae24642de2e71e0a6079a27aabae32132
Author: Stephen R. van den Berg
Date: Tue Feb 2
Tobias S. Josefowitz wrote:
>PIKE_T_FREE is only acceptable in a limited amount of places, and
>inside mappings is not one of them.
I do not insert it into a mapping, the size-calculation code tries to
just below this code fragment.
> In particular, as far as I
>understand, PIKE_T_FREEs should
Can anyone confirm that the following patch seems reasonable?
Or am I seeing the results of anomalies I created/missed in the
Buffer/Shuffler rewrites?
Memory size accounting error.
diff --git a/src/builtin_functions.c b/src/builtin_functions.c
index 52534409d7..993ba05611 100644
---
Thanks for fixing that.
Now I get this:
lib/modules/Standards.pmod/URI.pike:517:Wrong return type.
lib/modules/Standards.pmod/URI.pike:517:Expected: mapping(string:string).
lib/modules/Standards.pmod/URI.pike:517:Got : mapping(zero:zero).
This has been there for a few months already, BTW.
--
Tobias S. Josefowitz wrote:
>> But in 8.1+ mode, I could imagine omitting the compatibility wrappers from
>> the getgo.
>What's the proposed benefit for not having wrappers? They cost
>virtually nothing, we can easily carry them for ages to come... why
>break existing code?
No hard argument
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
>>Compression.Bz2
>>Compression.Gz
>>Compression.Lz4
>If we change location I want them to have the same API so you can
>switch between them easily. Old locations should have compatibility
>wrappers of course.
Same API, of course.
Stephen R. van den Berg wrote:
>11623
>11624 loop:
>11625/* Count the number of array levels. */
>11626while(fun_type->type == PIKE_T_ARRAY) {
>11627 array_cnt++;
>11628 fun_type = fun_type->cdr;
>11629}
>11630
>(gdb) p fun_type
>
Received signal SIGSEGV, Segmentation fault.
new_get_return_type (fun_type=0x0, flags=flags@entry=0) at
/home/srb/81pike/src/pike_types.cmod:11626
11626 while(fun_type->type == PIKE_T_ARRAY) {
(gdb) where
#0 new_get_return_type (fun_type=0x0, flags=flags@entry=0) at
For the new CQL driver I need Lz4 support.
Now, instead of introducing yet another toplevel Lz4 object, how about
moving Bz2 and Gz and Lz4 into:
Compression.Bz2
Compression.Gz
Compression.Lz4
Any objections?
--
Stephen.
Do they need to be weeded out manually? If so, how?
Or do they magically vanish and if so, when does that actually happen?
--
Stephen.
Tobias S. Josefowitz wrote:
>By the way, do you have any examples for when
>commit 7def00d27ac7a31be123aaf7b63299d612d5802c
>Stdio.Buffer: Do not optimise the buffer to empty if there are subbuffers.
>"generic data corruption bugs"? As far as I could see having a quick
>glance, all changes
Arne Goedeke wrote:
>The Stdio.Buffer output callback is required even for buffers which are
>not malloced. Now, the following test case
>Stdio.Buffer b = Stdio.Buffer("foo");
>b->__set_on_write(lambda(mixed ... args) { werror("New Data added.\n") });
>b->add("bar");
>does not work anymore. I
In an attempt to prepare the Shuffler for use on the database connection
in the pgsql module, I delved back into the Shuffler code again.
This time I achieved 99.9% comprehension of the code.
The result is a considerable rewrite of the inner loop.
The rewrite was necessary because:
a. The
Stephen R. van den Berg wrote:
>Any clue as to what I messed up here?
It seems that this is due to the broken state of pike-master at the moment.
--
Stephen.
Any clue as to what I messed up here?
Making dynamic: post_modules/SQLite
Making dynamic: post_modules/Shuffler
match_types mismatch!
a: zero
b: void
res: NULL
tmp: zero
tmp2: zero
match_types mismatch!
a: zero
b: void
res: NULL
tmp: zero
tmp2: zero
pike_types_le mismatch!
a:
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>Rather than change the API you could extend it to allow the capability
>to be queried more cheaply perhaps? If the target does not implement
>the extended API you'd just fall back to using strings.
Well, refactoring
Arne Goedeke wrote:
>Maybe a better strategy would be to introduce a new type of buffer
>object (supported by the get_memory_object_* APIs) which can be used
>to (cheaply) carry some arbitrary binary data. That is in principle
>already supported by Stdio.File()->write().
Well, three things come
Tobias S. Josefowitz wrote:
>for trouble. The GC might decide to run, I wouldn't necessarily expect
>that to work out - but then maybe it does, another thread might
I'd think that wouldn't be a problem, since all refs are accounted for.
>request a backtrace of your thread and non-hashed strings
>No that is not allowed. make_static_string() is an internal API to
>create string with static storage (e.g. compile time constant strings).
>If you want to pass this string to pike code you need to use
>make_shared_static_string() which creates a "normal" Pike string.
>What use-case do you have?
Is it allowed/supported to put a string created with make_static_string()
into an svalue and then give it to say the write() method of an arbitrary
Stdio object?
--
Stephen.
Did someone already try to ask someone at Lysator to push the power button?
I have, amongst other things, a fix for a fundamental data corruption bug
in Stdio.Buffer which I fixed in master and in 8.0 waiting to be uploaded
to the central git repository.
--
Stephen.
Stanislaw Klekot wrote:
>On Fri, Mar 12, 2021 at 10:40:03AM +0100, Stephen R. van den Berg wrote:
>> This seems like a bug:
>Note that the data type's name is *multi*set, so a *set* with
>*duplicates*. This behaviour is exactly what you should to expect after
>hearing the name.
This seems like a bug:
Pike v8.1 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
> (<"foo", "bar">) | (<"some", "bar">);
(1) Result: (< /* 3 elements */
"bar",
"foo",
"some"
>)
> (<"foo", "bar">) + (<"some", "bar">);
(2) Result: (<
Server crashed?
--
Stephen.
I have been eliminating some memory leaks from the Shuffler, while
running my SPike webserver. Things seem to have stabilised now.
However, when inspecting the memory footprint, I see the dump at the
bottom of this mail.
Now, in the grand scheme of things, 850.4kB might not be a lot, but
I'm
How does one change the DefaultBackend in Pike?
I tried something like:
int main(int argc, array(string) argv) {
Pike.DefaultBackend = Pike.PollDeviceBackend();
return -1;
}
Which results in: Illegal lvalue.
--
Stephen.
H William Welliver wrote:
>I tried merging current master (which itself was a surprisingly easy task),
> but pike fails to compile due to typechecker errors.
If you want to build a working recent master, you could do that
from commit 94a868dae24642de2e71e0a6079a27aabae32132
It's the last one that
Has anyone implemented a library to generate QR-codes in Pike throwing
out a PNG of some kind?
--
Stephen.
Stephen R. van den Berg wrote:
>commit 36a7c5f2c3b44f5556fc2a8e05051211b0e3d834
>Author: Henrik Grubbstrm (Grubba)
>Date: Wed Aug 26 17:44:39 2020 +0200
>Concurrent.Promise: Refactored the dependency handling.
>In systems with lots of long-lived promises running aro
Looking at:
commit 36a7c5f2c3b44f5556fc2a8e05051211b0e3d834
Author: Henrik Grubbstrm (Grubba)
Date: Wed Aug 26 17:44:39 2020 +0200
Concurrent.Promise: Refactored the dependency handling.
I find:
- final int _materialised;
- final AggregateState _astate;
+ protected
The fixes in master work, in that there are no segmentation faults anymore,
however, now I regularly get this:
(gdb) where
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7f010403c537 in __GI_abort () at abort.c:79
#2 0x56469288b3c0 in debug_va_fatal (
Another core stacktrace (core5):
[New LWP 31798]
[New LWP 28691]
[New LWP 31695]
[New LWP 31738]
[New LWP 31703]
[New LWP 31730]
[New LWP 31707]
[New LWP 31717]
[New LWP 31711]
[New LWP 31725]
[New LWP 31699]
[New LWP 31673]
[New LWP 31367]
[New LWP 31799]
[New LWP 31694]
[New LWP 31715]
[New LWP
Tobias S. Josefowitz @ Pike developers forum wrote:
>>Am I reading those correctly that both are upon thread creation?
>First, nice backtrace. I think it's more that any thread started ever
>will have been started by thread creation, and that's what we're
>seeing here, not that this necessarily
Stephen R. van den Berg wrote:
>Well, this experiment failed. I took out my reverts locally, and now
>changed the diagnostic Pike_error() in case of the already-destructed call
>into a Pike_fatal(), in hopes of finding out when it is being triggered
>from the next coredump.
This is
Stephen R. van den Berg wrote:
>Stephen R. van den Berg wrote:
>>Agreed. The trouble is finding them. The problems are triggered by
>>destruct-races, and therefore hard to reproduce under controlled
>>circumstances.
>I might have found something, in the Shuffler. T
Stephen R. van den Berg wrote:
>Agreed. The trouble is finding them. The problems are triggered by
>destruct-races, and therefore hard to reproduce under controlled circumstances.
I might have found something, in the Shuffler. The error (if it actually is
what we're looking for) was a
Tobias S. Josefowitz @ Pike developers forum wrote:
>They may work, but only in the sense that you are shielding yourself
>from the worst consequences of undefined/use-after-free/... memory
>access. Both your changes, the one checking io->output's type to be
>PIKE_T_FUNCTION and the
Stephen R. van den Berg wrote:
>Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
>>Not really; what does happen is that execution may return to a stack
>>frame in an object that has been destructed.
>Hmmm, ok. That would mean that a pikefun cannot be called aft
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
>> Entering destructed objects happens "all the time" when callbacks
>> to memberfunctions in already destructed objects are being called.
>Not really; what does happen is that execution may return to a stack
>frame in an object that
Tobias S. Josefowitz @ Pike developers forum wrote:
>>I can now confirm that I've been running three hours with io->this = 0 at
>>destruct, and there have not been any coredumps yet. Seems promising.
Four hours now, no coredump. Statistically relatively strong evidence.
>I'm still a bit
Stephen R. van den Berg wrote:
>>zero..., and if I am not mistaken we do not zero out CVAR Buffer
>>[aka struct _Buffer] on destruct or free either... what am I missing?
>Maybe you're not missing anything. I was assuming pike did this elsewhere
>on destruct. Apparently not, be
Tobias S. Josefowitz @ Pike developers forum wrote:
>>Stdio.Buffer: Protect against calls in destructed Buffer objects.
>#define CHECK_DESTRUCTED(io) ((io)->this ? (io) : already_destructed())
>I don't get how that works, nothing really ever sets io->this to
>zero..., and if I am not
Tobias S. Josefowitz @ Pike developers forum wrote:
>>Stdio.Buffer: Check for PIKE_T_FUNCTION before acting on objects.
>> src/modules/_Stdio/buffer.cmod | 19 +++
>> 1 file changed, 7 insertions(+), 12 deletions(-)
>>Both caused segmentation faults. Mostly because the
later, I found and fixed
two things:
commit 5884c9d61d11a8374e2feac0e4f211121468aea8
Author: Stephen R. van den Berg
Date: Sun Jul 19 23:55:26 2020 +0200
Stdio.Buffer: Protect against calls in destructed Buffer objects.
src/modules/_Stdio/buffer.c
Stephen R. van den Berg wrote:
>>When I spoke to Nisse about it ~half a year ago, it sounded like he
>>would likely accept such contributions, but would not implement it
>>himself.
>Ok, I submitted a working bcrypt() implementation to the
>nettle-bugs mailinglist (a sma
I think I found it.
commit be8d0c60fcd3bb8615740d55ba300460c9062679 (HEAD -> master)
Author: Stephen R. van den Berg
Date: Mon Jul 6 00:13:44 2020 +0200
Stdio.Buffer: Put null in a freed io->output.u.object.
src/modules/_Stdio/buffer.cmod | 4 +++-
1 file changed, 3 insertions
Stephen R. van den Berg wrote:
Recompiled with gcc-9 -O1 -g with RTL_DEBUG with valgrind support.
This time with:
--with-double-precision --with-long-int \
--disable-noopty-retry \
--with-poll \
--without-machine-code \
--with-portable-bytecode \
Valgrind repots:
http://hestia.cuci.nl
Recompiled with gcc-9 -O2 -g with RTL_DEBUG with valgrind support.
This time with:
--with-double-precision --with-long-int \
--disable-noopty-retry \
--with-poll \
--without-machine-code \
--with-portable-bytecode \
The program now delivers the right output, but the valgrind report(s)
Compiled with gcc-9 -O2 -g with RTL_DEBUG and with valgrind support.
The RTL_DEBUG results in this:
/usr/local/pike/8.1.13/lib/modules/SSL.pmod/Connection.pike.o:-: Warning:
Decode failed: Decode error: Got unfinished program <279> after decode: program
Running it under valgrind is a bit strange
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
>The above doesn't look like it is directly related to the mutex changes.
>I guess it could be a reference counting issue or a double free.
>What does "call gdb_backtraces()" output?
It's already a "cold" core. So that won't work.
This was when compiled with -g -O2 and no RTL_DEBUG.
I have a coredump factory now.
[New LWP 9071]
[New LWP 9048]
[New LWP 5670]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/bin/pike
Running without these commits, it runs forever.
Running with these commits results in segmentation faults every few minutes
to hours (this is in heavy threaded/lock code: pgsql driver).
I cannot offer a stacktrace yet.
commit 4781e5e4fe034cc8b2acef468131d5dbc51ca21f
Author: Henrik Grubbstr??m
The docs say this:
mixed `->(string index, object|void context, int|void access)
Parameter context
Context in the current object to start the search from. If UNDEFINED or left
out, this_program::this is to be be used (ie start at the current context
and ignore any overloaded symbols).
Can
Stephen R. van den Berg wrote:
>git clone git://devel2.cuci.nl/spike
It is production ready.
Rough featurelist:
- Meaningful error messages on compiled modules.
- Smart auto-recompilation of modules (mtime based).
- Auto-fallback to last-known-good modules on compilation failure.
- Two clas
Stephen R. van den Berg wrote:
>If I want this to print 12 (instead of 4), how do I need to tell
>Pike to access the c-member from b->set() in class a instead of the one
>in class b?
Hmmm, I vaguely remembered this topic has already been mentioned
on the mailinglist...
I found this ge
class a {
int c = 4;
class b {
int c = 3;
void set(int d) {
c = d; // FIXME
}
}
void runme() {
object y = b();
y->set(12);
}
}
object x = a();
x->runme();
write("a->c %d\n", x->c);
If I want this to print 12 (instead of 4), how do I need to tell
Pike
I'm using the following function in my spike-webserver:
object compileit(string file, void|int quiet) {
object prog;
if (!quiet)
log("Compiling %s", file);
if (mixed err = catch(prog = compile_file(file)()))
log(LOG_ERR, "Compile error %s", describe_backtrace(err));
return prog;
}
Stephen R. van den Berg wrote:
>git clone git://devel2.cuci.nl/spike
In case it wasn't obvious: Spike needs a fairly recent Pike from master
(from commit 2f9f4bdff4e (May 28th 2020 and newer).
--
Stephen.
Chris Angelico wrote:
>> I've written (for internal use) an HTTP daemon in Pike, using roughly
>> the following featureset:
>> If there is interest, I'll clean up the code a bit more, and make it
>> available
>> via a git repo somehwere.
Well, I put something preliminary up.
Take a look, and
Stephen R. van den Berg wrote:
>Once you have an accepted connection in Protocols.HTTP.Server.Request, is
>there a reference to the original listening socket the connection
>was accepted on?
Ah, I think I found something: server_port
seems to be a reference to the listening socket.
--
Stephen.
Once you have an accepted connection in Protocols.HTTP.Server.Request, is
there a reference to the original listening socket the connection
was accepted on?
Why don't we preset the set_id()/query_id() value on the accepted
socket with the one from the listening socket?
--
Stephen.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>Which of the (plethora of) MIME functions is the best for you depends
>a bit on your requirements. The ones with "words" in the name support
Thanks for the explanation. Maybe some of this should go into the MIME
docs
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>If you are referring to tokenization and and formatting of structured
>values of such headers, then MIME.tokenize and MIME.quote should be
>your friends. The detailed interpretation of the actual tokens would
The main
I've written (for internal use) an HTTP daemon in Pike, using roughly
the following featureset:
- Mainly meant to run (custom) pike modules processing requests.
- Also serves static content (through a simple config file).
- Supports multiple virtual servers, with multiple mountpoints each.
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>Which "parameters" are you referring to? Query encoding/decoding is
>already in Standards.URI. Header encoding/decoding exists in
>Protocols.HTTP.Query, although the decoding functions doesn't seem to
>be callable on
After having needed to program (HTTP) parameter decoding/encoding for the nth
time, I decided to add some proper code for generic use.
Any objections to the interface and/or naming?
Is the solution fast enough?
--
Stephen.
The Pike side of the bcrypt verify/hash support has been committed now.
If there are still issues with the Nettle side, let me know.
--
Stephen.
Niels M?ller (entering a radioactive zone) @ Pike (-) developers forum wrote:
>What systems is it important to interop with? System password/shadow
>files, defined by BSD and GNU libc, or PHP applications?
Both.
>And the other bug mentioned affects only input passwords that are
>longer than 255
Niels M?ller (entering a radioactive zone) @ Pike (-) developers forum wrote:
>All the extra complexity for bug compatibility, is that still
>relevant? Is anyone using the $2a$, $2x$, $2y$ variants? What's done
>in BSD and GNU libc?
Being able to actually verify encoded old entries would seem
>> What are my chances of getting it added to Nettle?
>> Or would adding it to Pike only, be easier?
>When I spoke to Nisse about it ~half a year ago, it sounded like he
>would likely accept such contributions, but would not implement it
>himself.
Ok, I submitted a working bcrypt()
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
>> Has anyone attempted to add support for Blowfish encryption to
>> Crypto.Password?
>> I have some $2y$... prefixed passwords (interfacing with the PHP
>> password_verify()) which I need to verify.
>I've looked into it briefly. As
Has anyone attempted to add support for Blowfish encryption to Crypto.Password?
I have some $2y$... prefixed passwords (interfacing with the PHP
password_verify()) which I need to verify.
--
Stephen.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>>Other threads *are* allowed to add() to the end of the buffer, but nothing
>>else. Releasing the interpreter lock for just doing that should not be
>>necessary?
>Without releasing the interpreter lock, no other pike
Arne Goedeke wrote:
>This sounds like something which could be connected to the fact that
>Stdio.File()->write(Stdio.Buffer()) does not release the interpreter
>lock. This makes it less useful for situations where write is not
>called from within one backend thread. This makes me think that in
Tobias S. Josefowitz @ Pike developers forum wrote:
>>As to what exactly goes wrong...
>>What I can report is that using that commit, it mostly works, until the
>>scheduling gets tight. I.e. under intense pgsql query load, things go
>>wrong. So that suggests that there might be issues that occur
Arne Goedeke wrote:
>Commit 20d1fa961d0059657d471d700ce63bcb3ab9d3ca mentions that there is a
>bug in the Stdio.Buffer support in Stdio.File()->write() (I assume).
>Stephen, can you explain how it is broken? Do you have a test case? Does
>it have something to do with the fact that you are using a
Can it be considered a bug that when you add a duplicate key to
an ADT.OrderedMapping() that it does add the key/value at the end, but
fails to delete the already present same old key (value)?
Shall I fix it?
--
Stephen.
Stephen R. van den Berg wrote:
>https://www.npmjs.com/package/remixml
(The RXML inspired macro-language).
The Remixml module has been rewritten and now actually works
as a Remixml-to-Javascript compiler.
I.e. the module itself is written in Javascript, it runs in the browser
and conve
FYI:
$ pike
Pike v8.1 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
> object x = Crypto.MAC()->State("secretp");
Segmentation fault
It might be abuse of the API (I was trying to find an incantation to
create a secret to be used for JWT generation), but a segfault would
not be
1 - 100 of 710 matches
Mail list logo
