Pike 8.0.460 beta candidate:
https://pike.lysator.liu.se/pub/pike/beta/8.0.460/Pike-v8.0.460.tar.gz
Other builds:
https://pike.lysator.liu.se/pub/pike/beta/8.0.460/Pike-v8.0.460-Darwin-15.4.... https://pike.lysator.liu.se/pub/pike/beta/8.0.460/Pike-v8.0.460-win32-oldlib...
This is not a release candidate. There are some changes without CHANGES and I'm not quite comfortable with the namespace the Debug.Peek functionality is living in.
Changes since Pike 8.0.438 (release 9) ----------------------------------------------------------------------
New Features ------------
o Concurrent
The Concurrent module simplifies asynchronous code by synchronizing events in different ways. As an example the connect() function shown below will respond with a Concurrent.Future object that at some point will represent either a connected socket or a failure.
Concurrent.Future connect(string host, int port) { Stdio.File con = Stdio.File(); Concurrent.Promise p = Concurrent.Promise(); if( !con->async_connect(host, port, lambda(int success) { if(success) p->success(con); else p->failure("Failed to connect to "+host+":"+port+"\n"); })) { p->failure("Failed to open socket.\n"); } return p->future(); }
The returned future can then be used in various ways.
// On success, call make_request(con, query). On failure call // werror(msg). connect(host, port) ->on_failure(werror) ->on_success(make_request, query);
// On success, call make_request(con, query1) followed by // make_request(resp, query2), where resp is the return value from // make_reqest. connect(host, port) ->then(make_request, werror, query1) ->then(make_request, werror, query2);
// Call bridge_ports(con1, con2) when both connections are // established. Concurrent.all(connect(host1, port1), connect(host2, port2)) ->then(bridge_ports, failure);
// Call make_request(con) once either of the connections are // established. Concurrent.race(connect(host1, port1), connect(host2, port2)) ->then(make_requet, query);
o Filesystem.Monitor
- Changed the polling heuristic.
This is intended to reduce poll (and notification) delays in some circumstances.
- Improved robostness of adjust_monitor().
- Removed some dead and obsolete code.
- Scan accelerated monitors too.
Both the Inotify and FSEvents APIs claim that they support notifications on eg network file systems, and while they will succeed in notifying on changes performed by the local host on such file systems, they will not on changes performed by other hosts. To avoid missing such changes these monitors need to be actively scanned too.
o Sql.pgsql
Sped up BEGIN/COMMIT statements. Preserve the initial error message in case of multiple error messages during the same transaction. Flush out unseen error messages upon connection close to stderr.
o Debug.Peek
Allows for interactive debugging and live data structure inspection in both single- and multi-threaded programs.
Example: In the program you'd like to inspect, insert the following one-liner: Debug.Peek("/tmp/test.pike");
Then start the program and keep it running. Next you create a /tmp/test.pike with the following content: void create() { werror("Only once per modification of test.pike\n"); }
int main() { werror("This will run every iteration\n"); werror("By returning 1 here, we disable the stacktrace dumps\n"); return 0; }
void destroy() { werror("destroy() runs just as often as create()\n"); }
Whenever you edit /tmp/test.pike, it will automatically reload the file.
Bug fixes ---------
o Search
Fixed a race condition when updating the database.
o Parser.HTML
Fixed a condition where Pike would run out of stack space for large documents.
o ADT.Heap
Fixed heap corruption when the same object is pushed more than once. It will now be considered as calling adjust().
o Inotify
Addressed an issue where the backend might be stuck in pending indefinitely.
o FSEvents
EventStreamMonitor now works with other backends.
o Standards.BSON
Fixed incorrect encoding/decoding of Binary data.
o Stdio.Buffer
Fixed a crash when attempting to create a rewind key on a buffer returned by read_buffer().
o mappings
Fixed an off by one error in random(mapping) that randomly caused values of type PIKE_T_FREE from the freelist to be exposed to Pike.
o Sql.pgsql
Closed a prepared-statement-cache race when the same statement is offered multiple times before it finalises the cache entry. Fix sync errors with the database in case of multiple running statements on a single connection that generate multiple errors.
Peter Bortas wrote:
This is not a release candidate. There are some changes without CHANGES and I'm not quite comfortable with the namespace the Debug.Peek functionality is living in.
Any suggestions with regard to where Debug.Peek should live? I'll comb through the pgsql fixes I committed, some of those were cosmetic though, not worthy of a CHANGES entry.
On Wed, Jul 5, 2017 at 10:04 AM, Stephen R. van den Berg srb@cuci.nl wrote:
Peter Bortas wrote:
This is not a release candidate. There are some changes without CHANGES and I'm not quite comfortable with the namespace the Debug.Peek functionality is living in.
Any suggestions with regard to where Debug.Peek should live?
Not yet, _my_ primary concern is that it doesn't do anything I would expect with that name. A Peek better come with a Poke. Due to the LysKOM-exporter being busted again* I also don't think you've seen Nilsson's comment:
srb>>I'd appreciate feedback on the implementation and usability of Debug.Peek srb>>(in Pike 8.1).
nilsson>Isn't this more of an application than a module? I.e. shouldn't this nilsson>rather be in the bin directory or in Tools.Standalone?
* I've agreed to take it over, but the final move hasn't been done yet.
I'll comb through the pgsql fixes I committed, some of those were cosmetic though, not worthy of a CHANGES entry.
I didn't see any checkins from you missing in CHANGES. It was something originating from Roxen.
Regards,
Peter Bortas wrote:
Not yet, _my_ primary concern is that it doesn't do anything I would expect with that name. A Peek better come with a Poke. Due to the
At first I called it Debug.Threads. Then I realised that it's more than that. But if anyone knows a better name: by all means!
LysKOM-exporter being busted again* I also don't think you've seen
Sigh...
nilsson>Isn't this more of an application than a module? I.e. shouldn't this nilsson>rather be in the bin directory or in Tools.Standalone?
It can't run by itself, it needs to be called/linked into the program that you need to inspect with it. Ah, maybe: Debug.Inspect ?
Stephen R. van den Berg wrote:
LysKOM-exporter being busted again* I also don't think you've seen
Sigh...
Might I remind everyone of this fact: I have to guess what people respond to things I post here. The only real feedback I get are commits :-(.
nilsson>Isn't this more of an application than a module? I.e. shouldn't this nilsson>rather be in the bin directory or in Tools.Standalone?
It can't run by itself, it needs to be called/linked into the program that you need to inspect with it. Ah, maybe: Debug.Inspect ?
I'm going to rename Debug.Peek to Debug.Inspect later today (unless anyone actually sends me an email about this matter).
On Mon, Jul 10, 2017 at 4:16 PM, Stephen R. van den Berg srb@cuci.nl wrote:
Stephen R. van den Berg wrote:
I'm going to rename Debug.Peek to Debug.Inspect later today (unless anyone actually sends me an email about this matter).
Committed.
Great! I'll see if I can roll out a release candidate soon.
pike-devel@lists.lysator.liu.se