text:
Manual "tick" execution

I suggest adding a manual tick() call to the loop:
interface LoopInterface
{
    // ...

    public function tick(): void;
}

In this case, the implementation of the run() method will be as follows:
public function run()
{
    $this->running = true;

    while ($this->running) {
        $this->tick();
    }
}

Such functionality is extremely necessary if the implementation uses its own event loop.
Such cases are needed when you need to implement additional functionality, for example, add support for high-performance tick handlers. For example:
class MyLoop
{
     public function __construct(LoopInterface $parent) { ... }

    public function run(): void
    {
        while(true) {
            $now = \microtime(true);
            $delta = $now - $this->updated;

            // custom operations
            foreach ($this->ticks as $handler) {
                $handler($delta);
            }

            $this->parent->tick();

            $this->updated = $now;
        }
    }
}

We already have a futureTick queue, which runs callback functions in the same way..isn't it a similar feature?
/**
 * Flush the callback queue.
 */
public function tick()
{
    // Only invoke as many callbacks as were on the queue when tick() was called.
    $count = $this->queue->count();

    while ($count--) {
        \call_user_func(
            $this->queue->dequeue()
        );
    }
}

We can do something like that:
public function run()
{
    $this->baseEventLoop->futureTick(fn () => $this->tick());

    $this->baseEventLoop->run();
}

// will be executed on each while(isRunning) iteration of the baseEventLoop
private function tick(): void
{
    // exception bubbling is not allowed here
    try {
        // our work
    } catch (Throwable $exception) {
        // handle exceptions and errors
    }

    // repeat
    $this->baseEventLoop->futureTick(fn () => $this->tick());
}

Or call_user_func and queue push/pop operations are "too slow" things for the original task and it is not acceptable?
Still learning reactphp, but i think the core concept was.. If any performance-heavy component wants to become "async" in our reactphp environment, it should start to request execution time from the centralized (single) event loop, not command event loop internals directly (as a separate "loop"). Am i correct here? So, we have timers and tick queue api.
Furthermore, we can try to hide loop existence (timers, ticks) on the user-side / business layer (if we cooking a "native" reactphp app). I would suggest something like getTime(): PromiseInterface sugar alongside existing levers, in the same manner, but it will be, probably, a bad move, because the EventLoop is designed as a low-level unit.. :)
(it looks like this):
/**
 * Returns a promise that resolves to a list of hardware items, found on the website using a remote browser.
 *
 * The resulting collection represents a Traversable<Item> or Item[].
 *
 * @param BrowserContext $browserContext Holds browser state and a driver reference to perform actions
 *
 * @return PromiseInterface<iterable>
 */
public function readItems(BrowserContext $browserContext): PromiseInterface
{
    $browsingThread = $browserContext->getBrowsingThread();

    $lookupDeferred = new Deferred();

    $tabReadyPromise = $browsingThread
        // acquiring a time frame in the shared event loop.
        ->getTime()
        // opening a tab in the remote browser, where we will analyse a web resource with hardware list.
        ->then(fn () => $this->openBrowserTab($browserContext))
    ;

    $resourceAccessPromise = $tabReadyPromise
        // accessing a page with hardware list.
        ->then(fn () => $this->accessResource($browserContext))
    ;

    $resourceAccessPromise
        // loading a page source.
        ->then(fn () => $this->readSourceCode($browserContext))
        // extracting a hardware list from the page.
        ->then(fn (string $rawData) => $this->itemParser->parse($rawData))
        // handling errors and releasing a thread lock.
        ->then(
            function (iterable $hardwareItems) use ($browsingThread, $lookupDeferred) {
                $browsingThread->release();

                $lookupDeferred->resolve($hardwareItems);
            },
            function (Throwable $rejectionReason) use ($browsingThread, $lookupDeferred) {
                $browsingThread->release();

                $reason = new RuntimeException('Unable to lookup hardware items.', 0, $rejectionReason);
                $lookupDeferred->reject($reason);
            }
        )
    ;

    $itemListPromise = $lookupDeferred->promise();

    return $itemListPromise;
}

$browsingThread is just a wrapper under loop->addTimer call and some other execution flow control (ticks, delays).
btw: "fn () => ..." is pretty ok for debugging (tested with xdebug 3) and rejections/retvals are well forwarded.

We already have a futureTick queue, which runs callback functions in the same way..isn't it a similar feature?
/**
 * Flush the callback queue.
 */
public function tick()
{
    // Only invoke as many callbacks as were on the queue when tick() was called.
    $count = $this->queue->count();

    while ($count--) {
        \call_user_func(
            $this->queue->dequeue()
        );
    }
}

We can do something like that:
public function run()
{
    $this->baseEventLoop->futureTick(fn () => $this->tick());

    $this->baseEventLoop->run();
}

// will be executed on each while(isRunning) iteration of the baseEventLoop
private function tick(): void
{
    // exception bubbling is not allowed here
    try {
        // our work
    } catch (Throwable $exception) {
        // handle exceptions and errors
    }

    // repeat
    $this->baseEventLoop->futureTick(fn () => $this->tick());
}

Or call_user_func and queue push/pop operations are "too slow" things for the original task and it is not acceptable?
Still learning reactphp, but i think the core concept was.. If any performance-heavy component wants to become "async" in our reactphp environment, it should start to request execution time from the centralized (single) event loop, not command event loop internals directly (as a separate "loop"). Am i correct here? So, we have timers and tick queue api.
Furthermore, we can try to hide loop existence (timers, ticks) on the user-side / business layer (if we cooking a "native" reactphp app). I would suggest something like getTime(): PromiseInterface sugar alongside existing levers, in the same manner, but it will be, probably, a bad move, because the EventLoop is designed as a low-level unit.. :)
(it looks like this):
/**
 * Returns a promise that resolves to a list of hardware items, found on the website using a remote browser.
 *
 * The resulting collection represents a Traversable<Item> or Item[].
 *
 * @param BrowserContext $browserContext Holds browser state and a driver reference to perform actions
 *
 * @return PromiseInterface<iterable>
 */
public function readItems(BrowserContext $browserContext): PromiseInterface
{
    $browsingThread = $browserContext->getBrowsingThread();

    $lookupDeferred = new Deferred();

    $tabReadyPromise = $browsingThread
        // acquiring a time frame in the shared event loop.
        ->getTime()
        // opening a tab in the remote browser, where we will analyse a web resource with hardware list.
        ->then(fn () => $this->openBrowserTab($browserContext))
    ;

    $resourceAccessPromise = $tabReadyPromise
        // accessing a page with hardware list.
        ->then(fn () => $this->accessResource($browserContext))
    ;

    $resourceAccessPromise
        // loading a page source.
        ->then(fn () => $this->readSourceCode($browserContext))
        // extracting a hardware list from the page.
        ->then(fn (string $rawData) => $this->itemParser->parse($rawData))
        // handling errors and releasing a thread lock.
        ->then(
            function (iterable $hardwareItems) use ($browsingThread, $lookupDeferred) {
                $browsingThread->release();

                $lookupDeferred->resolve($hardwareItems);
            },
            function (Throwable $rejectionReason) use ($browsingThread, $lookupDeferred) {
                $browsingThread->release();

                $reason = new RuntimeException('Unable to lookup hardware items.', 0, $rejectionReason);
                $lookupDeferred->reject($reason);
            }
        )
    ;

    $itemListPromise = $lookupDeferred->promise();

    return $itemListPromise;
}

$browsingThread is just a wrapper under loop->addTimer call and some other execution flow control (ticks, delays).
btw: "fn () => ..." is pretty ok for debugging (tested with xdebug 3) and rejections/retvals are well forwarded.

isn't it a similar feature?

Looks like nope.
In your example, you are just subscribing to "ticks". In my example, this is a manual call of the "tick" method which can already execute the necessary logic (for example, call "tick subscribers").
$loop->futureTick(fn() => null); // << Subscription (onTick)
$loop->tick(); // << Imperative tick execution

That is, I propose to move this code into a separate method: https://github.com/reactphp/event-loop/blob/master/src/StreamSelectLoop.php#L182-L212

isn't it a similar feature?

Looks like nope.
In your example, you are just subscribing to "ticks". In my example, this is a manual call of the "tick" method which can already execute the necessary logic (for example, call "tick subscribers").
$loop->futureTick(fn() => null); // << Subscription (onTick)
$loop->tick(); // << Imperative tick execution

That is, I propose to move this code into a separate method: https://github.com/reactphp/event-loop/blob/master/src/StreamSelectLoop.php#L182-L212

If you have your own event loop, why not wrap the event loop in a class that implements the reactphp event loop interface?
I think that would be the better way than make an event loop compatible with an outside event loop. Going down the tick route would break encapsulation and isolation and provide great surface for races and hard to track down bugs.

If you have your own event loop, why not wrap the event loop in a class that implements the reactphp event loop interface?
I think that would be the better way than make an event loop compatible with an outside event loop. Going down the tick route would break encapsulation and isolation and provide great surface for races and hard to track down bugs.

If you have your own event loop, why not wrap the event loop in a class that implements the reactphp event loop interface?

Because the implementation of custom event loop may not be compatible with reactphp interface. For example, there may be no support for signals, timers and resource streams... Like this: https://github.com/SerafimArts/opengl-demo/blob/master/engine/src/EventLoop/OrderedEventLoop.php#L51-L63
And even if we used standard implementations of reactphp via delegation, it would not work due to the lack of a mechanism for imperatively calling ticks:
class CustomLoop implements LoopInterface
{
    public function __construct(private LoopInterface $parent) { ... }

    public function addReadStream($stream, $listener)
    {
        $this->parent->addReadStream($stream, $listener);
    }

    // etc...

    public function run(): void
    {
        while($this->running) {
            // My own operations

            $this->parent->tick(); // << I cant do that
        }
    }
}

Therefore, I propose to add a tick method so that reactphp loop delegation can be used correctly.

If you have your own event loop, why not wrap the event loop in a class that implements the reactphp event loop interface?

Because the implementation of custom event loop may not be compatible with reactphp interface. For example, there may be no support for signals, timers and resource streams... Like this: https://github.com/SerafimArts/opengl-demo/blob/master/engine/src/EventLoop/OrderedEventLoop.php#L51-L63
And even if we used standard implementations of reactphp via delegation, it would not work due to the lack of a mechanism for imperatively calling ticks:
class CustomLoop implements LoopInterface
{
    public function __construct(private LoopInterface $parent) { ... }

    public function addReadStream($stream, $listener)
    {
        $this->parent->addReadStream($stream, $listener);
    }

    // etc...

    public function run(): void
    {
        while($this->running) {
            // My own operations

            $this->parent->tick(); // << I cant do that
        }
    }
}

Therefore, I propose to add a tick method so that reactphp loop delegation can be used correctly.

FYI here is the PR where we removed the tick method and why: https://github.com/reactphp/event-loop/pull/72

FYI here is the PR where we removed the tick method and why: https://github.com/reactphp/event-loop/pull/72

Oh, there it is like...
This method was specially removed so that no one could get into the internal behavior of the event loop.
Perhaps this is logical, but it makes it impossible to use reactphp solutions as auxiliary =(
In any case, if this functionality was specifically removed, then no one will return it back. So this ischeu is no longer relevant. @WyriHaximus thank you!

Oh, there it is like...
This method was specially removed so that no one could get into the internal behavior of the event loop.
Perhaps this is logical, but it makes it impossible to use reactphp solutions as auxiliary =(
In any case, if this functionality was specifically removed, then no one will return it back. So this ischeu is no longer relevant. @WyriHaximus thank you!

@SerafimArts let me look into this thread, not sure how I missed it. There might be another way

@SerafimArts let me look into this thread, not sure how I missed it. There might be another way

@SerafimArts Love the project you're working on, this is a really interesting use case! ❤
As @WyriHaximus has pointed out, we used to have a tick() method that was intentionally removes as per #72. There's some good discussion about this in the ticket, but if we feel there's value in bringing it back in the future, we're open to discuss this further :+1:
That being said, I've checked the internals and the following piece of code perform the exact same logic as a hypothetical tick() method:
$loop->futureTick(function () use ($loop) {
    $loop->stop();
});
$loop->run();

I agree this looks a bit more expensive, but this shouldn't have noticeable more overhead than directly invoking a tick() method.
Either way, keep us posted with your OpenGL/SDL demo 👍

@SerafimArts Love the project you're working on, this is a really interesting use case! ❤
As @WyriHaximus has pointed out, we used to have a tick() method that was intentionally removes as per #72. There's some good discussion about this in the ticket, but if we feel there's value in bringing it back in the future, we're open to discuss this further :+1:
That being said, I've checked the internals and the following piece of code perform the exact same logic as a hypothetical tick() method:
$loop->futureTick(function () use ($loop) {
    $loop->stop();
});
$loop->run();

I agree this looks a bit more expensive, but this shouldn't have noticeable more overhead than directly invoking a tick() method.
Either way, keep us posted with your OpenGL/SDL demo 👍

This is not the only example where this use case was required, it was just the most obvious.
@WyriHaximus @clue thanks for help. I think that case with futureTick + stop + run is a perfectly valid substitute.
@itnelo sorry, the first time I didn't understand what you meant in ur code =)

This is not the only example where this use case was required, it was just the most obvious.
@WyriHaximus @clue thanks for help. I think that case with futureTick + stop + run is a perfectly valid substitute.
@itnelo sorry, the first time I didn't understand what you meant in ur code =)

@SerafimArts Bear in mind that your CPU usage will rise when the event loop isn't busy. But I'm not sure how that will work the other way around

@SerafimArts Bear in mind that your CPU usage will rise when the event loop isn't busy. But I'm not sure how that will work the other way around

authors: SerafimArts WyriHaximus clue gitneko itnelo

repo: reactphp/event-loop


text:
Fix for PHP 7 fatal error on duplicate parameter names in closures

PHP 7 does not like duplicate parameter names: https://3v4l.org/usQhl

The build failed on PHP 5.5 because the composer.json requires PHPUnit version that requires PHP 5.6.

That is interesting because the 5.4 build didn't fail. We don't specify phpunit in composer.json, the phpunit versions are supplied by travis

The changes LGTM and make perfect sense :+1:
Though I'm a bit surprised, has #27 been solved yet? Afaict nobody has managed to build the required extensions, so this code will not actually run? (Only the StreamSelectLoop should work)

Event 2.0 has been released with full PHP7 support. What is needed to get this to be merged?

We are already using PECL event 2.0 extension with PHP 7.0.3 with this patch and everything works fine.

@ondrejmirtes I'm busy patching our local install. Wondering when this will end up in a event-loop release.

I will contact ReactPHP maintainers in order to ask them what can we do to bring ReactPHP up to speed.

https://github.com/reactphp/event-loop/pull/45 includes this fix and adds also tests for php 7.

Wondering when this will end up in a event-loop release.

At the moment the above changes are not tested in our CI setup. I assume this will be accepted once we come up with some installation instructions for the required extensions, so perhaps anybody may help with #27 or #45?

@clue #45 is ready to merge. libev and libevent do not support php7 so there is nothing to fix from our side  atm.

Merged in via #45

source: gharchive/pull-request

authors: WyriHaximus cboden cebe clue dakota ondrejmirtes

license: mit

license_type: permissive

license_source: bigquery


text:
createSocket () how to use ?

accessSomeRemoteResource inside the createSocket () how to use, can give an example?

This is just some pseudo code to ease getting your started. You may want to use a higher level abstraction such as an HTTP client or Redis, MySQL etc.
I hope this helps :+1:

source: gharchive/issue

authors: clue kakuilan

repo: reactphp/promise-timer


text:
fix: handling of multipart/form-data requests and how we interact with FormData

Did you know that multipart/form-data requests is a HARD problem? And one that we're completely fumbling to solve right now to the point where some requests are being corrupted?
📖 Story time!
The most popular NPM package for handling the FormData API in Node, form-data, has a wholly non-spec compliant implementation of FormData. Not only does it ship an .append() API that has a non-compliant third argument, but it also supports file buffers. It also doesn't have an .entries() API so if you want to retrieve data out of it you need to pipe it through a Node stream.
Normally this wouldn't be a problem because if you're using form-data it's because you're in an environment where you don't have the native FormData API available to you. This obviously isn't the case for this library as we target both Node and browsers.
Well, that's fine because node-fetch suggests formdata-node and formdata-polyfill instead. Yeah...

formdata-polyfill is now an ESM-only package and the non-ESM version is no longer receiving updates, nor does it expose itself in a way that we can use it.
formdata-node works great... but requires you to use an encoder in order to use it with node-fetch@2. node-fetch@3 supports it on its own but is... you guessed it... an ESM-only package now.

Everything's fine I swear.

🏚 What we're doing wrong now
The way we're handling things currently is that because form-data doesn't expose .entries() API we can easily detect if it's form-data and not the real thing. When we encounter this we've got some branching logic to handle this non-compliant .append() API, and that works all just fine and dandy.
Not! haha got em

Because fetch-har is HAR based for files we're relying on Data URLs that we generate in our reference guide.
Because Data URLs are base64 encoded strings, if you base64 encode say the OpenAPI petstore example you're going to have a massive HAR.
Want to upload a binary? Yeah good luck with that, we can't handle that at all right now.
Want to upload an image? This sort of works, but we have bad logic currently where when we decode the data URL to supply it to the Blob API for FormData we're supplying a buffer -> string copy out of the data URL. This corrupts images!

🧰 What's being changed?
Still here? A lot's been changed to resolve [gestures at everything].
Starting off we're no longer allowing folks to use the non-compliant form-data package with this library. There are compliant options out there that don't require us to have gross hacks in place to support. If we detect that your FormData API is actually form-data, or otherwise non-compliant, we'll throw a hard error. Beyond that it gets a bit in the weeds:

[x] We're now supporting multipart/alternative, multipart/mixed, and multipart/related requests. These function identicaly to multipart/form-data.
[x] The existing userAgent second argument to fetch-har has been reworked into being an options object.
[x] A new files option has been added into this reworked argument. This option is a file -> Buffer|File mapping that folks can use if they don't want to, or don't have data URLs in their HAR for files.

In our reference guide this will start allowing us to accept large file uploads without having to deal with data URL conversions.

[x] A new multipartEncoder option has been added to supplement the formdata-node and node-fetch@2 interdependency that requires you to use form-data-encoder.

This is only a requirement if you're on Node and using node-fetch@2.
I should note that you definitely can't load form-data-encoder in the browser because it uses lookbehind regex that crashes the page in Safari; something I found out the hard way.

On a less exciting front I've also completely rewritten the test suite, because why not tack on another refactor to a refactor.

[x] Moved the test suite from using Jest to Mocha + Chai.

As much as I enjoy working with Jest, moving these tests over to Mocha allows us to use the same test code in all environments. More on that in a sec.

[x] All tests are now full integration tests that call https://httpbin.org

The existing mocks were fine but I have more confidence in seeing a real web server interact with and respond to requests this library is making. This has also allowed me to bulk up the tests for file uploads to make sure that they're actually working right.

[x] The existing browser suite that was using Puppeteer has also been moved over to Karma so we now have full coverage across Chrome, Firefox, and Safari.

And tests run on Windows in CI now too. 💅
🧬 Testing
There is a lot going on here, but everything is fully tested in Node, Chrome, Firefox, and Safari.  To run the Node test suite run npm test as you normally would.
For the run the browser tests you'll need to do the following:

Run npm test:browser
When Safari opens you'll need to click the open button to load the Karma runner as Safari requires user feedback (https://github.com/karma-runner/karma-safari-launcher/issues/29)
Wait

https://user-images.githubusercontent.com/33762/150459331-2a726af6-b306-443b-bed8-884de0b1b16d.mov
If you don't believe me that file uploads actually work now, give it a run yourself:
/* eslint-disable import/no-extraneous-dependencies, no-console */
require('isomorphic-fetch');
const fetchHar = require('.');
const parseDataUrl = require('parse-data-url');
const fs = require('fs').promises;
const { FormDataEncoder } = require('form-data-encoder');
const harExamples = require('har-examples');

globalThis.Blob = require('formdata-node').Blob;
globalThis.File = require('formdata-node').File;
globalThis.FormData = require('formdata-node').FormData;

fetchHar(harExamples['multipart-data-dataurl'], { multipartEncoder: FormDataEncoder })
  .then(res => res.json())
  .then(async res => {
    console.log(res);

    await fs.writeFile('image.png', parseDataUrl(res.files.foo).toBuffer());
  });

This code will upload an encoded image from a HAR (here) and then download and save what httpbin sent back. If you open up image.png you'll be greeted with a familiar face.
If you however you run this same HAR through the current release of fetch-har the call to parse-data-url on res.files.foo will fail because the contents of res.files.foo are corrupted:
require('isomorphic-fetch');
const fetchHar = require('fetch-har');
const parseDataUrl = require('parse-data-url');
const fs = require('fs').promises;
const harExamples = require('har-examples');

global.fetch = require('node-fetch');
global.Headers = require('node-fetch').Headers;
global.Request = require('node-fetch').Request;
global.FormData = require('form-data');

fetchHar(harExamples['multipart-data-dataurl'])
  .then(res => res.json())
  .then(async res => {
    console.log(res);

    await fs.writeFile('image.png', parseDataUrl(res.files.foo).toBuffer());
  });

{
  args: {},
  data: '',
  files: {
    foo: '�PNG\r\n' +
      '\x1A\n' +
      '\x00\x00\x00\rIHDR\x00\x00\x00\n' +
      '\x00\x00\x00\f\b\x06\x00\x00\x00[k,�\x00\x00\x01WIDATx\x01cp/�a�Q��U�\x10�\x06��1???��\x00�9�\r\x16p�W�I��j\x02\t�$Ab@��c��f�"�\n' +
      "W\bRT\x1Eh�#�J�IY���`��Q\x0E\x06�s��_z\x1B�Ԣ(�M��ߘ\x1D��&��?�\x1D�d��QK.\r��8+e��M\x1B�����ύ���v��MM����C�ì\x06;�$9��ľ��n.V��7��_6��\x7Fp�?\x18�k+l\x05�\x01��<��\x05�:�im��\x13�\f~\x01�`�A�\x06�a�U\x10�\x06rפ4��=�N(����\x7F���\x7F�\x1A\x06ce�� ��E>p<��\x0BL\x03\r\x00+�S\x10�� +��\x032\x1E�\x00���y�\x15�\x1A*�\x03�\x01��T]8� ��'�z���\x04{�[��W�b\r�0ŗA;ɇ����܉8\x17�[ �k)�\x10$f�� \rR\x03\x00���I��چ\x00\x00\x00\x00IEND�B`�"
  },
  form: {},
  headers: {
    Accept: '*/*',
    'Accept-Encoding': 'gzip,deflate',
    'Content-Length': '915',
    'Content-Type': 'multipart/form-data;boundary=--------------------------410362018522492426091525',
    Host: 'httpbin.org',
    'User-Agent': 'node-fetch/1.0 (+https://github.com/bitinn/node-fetch)',
    'X-Amzn-Trace-Id': 'Root=1-61ea47c0-5c15ca78234107880a7aa011'
  },
  json: null,
  origin: '98.42.248.146',
  url: 'https://httpbin.org/post'
}
(node:10510) UnhandledPromiseRejectionWarning: TypeError: parseDataUrl(...).toBuffer is not a function
    at /Users/erunion/Desktop/test/index.js:17:65
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:10510) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:10510) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Yikes!

I'm guessing this is a major version bump right? 😅 (Not looked at the code yet)

@ilias-t we should consider integrating this in the Metrics Service!

authors: domharrington erunion gratcliff

repo: readmeio/fetch-har

license: ISC

license_source: github-api


text:
Ping latency test locks up on multiple runs

Start the LowLatency media driver in one console. Start the Pong responder in another console. Then run the Ping latency client in a third console. If the ping test is done multiple times by selecting "y" then it eventually locks up and does not respond.

It can also fail to complete on a single run with a large enough run of sample messages, e.g. > 1 million.

It can also fail to complete on a single run with a large enough run of sample messages, e.g. > 1 million.

repo: real-logic/Aeron


text:
sbe.target.language value for c++ stubs

Hi,
What should the value of the 'sbe.target.language' option be for the SbeTool to
generate c++ stubs ?
Thanks

Hi,
what should be the correct syntax for generating C++ stubs:
i am using below command it fails:
java -sbe.target.language=cpp98 -jar sbe-1.0.1-RC2.jar example-schema.xml

You are missing the "-D" from the Java system properties.
-Dsbe.target.language=cpp98

Thanks you :100:  :+1:

repo: real-logic/simple-binary-encoding


text:
[Improve]: Add queue duration to Music Player

now queus duration is just showing the songs to play next duration. but update that to the total played duration / total duration

update player button interaction message. add the information of who has interacted with the button

Change back to previous style of progress bar

repo: realDarkCode/DarkBot

license: MIT


text:
Realm clears models' records after app launched.

I'm using v1.0.0;
I have simple model:
@interface KeyValue : RLMObject
@property NSString *key;
@property NSString *value;
+ (void)addValue:(NSString *)theValue forKey:(NSString *)theKey;
@end

@implementation KeyValue

+ (NSString *)primaryKey {
    return @"key";
}
+ (void)addValue:(NSString *)theValue forKey:(NSString *)theKey
{
    RLMRealm *realm = [RLMRealm defaultRealm];
    KeyValue *object = [KeyValue objectForPrimaryKey:theKey];

    if(!object) {
        object = [KeyValue new];
        object.key = theKey;
        object.value = theValue;

        [realm beginWriteTransaction];
        [realm addObject:object];
        [realm commitWriteTransaction];
    } else {
        [realm beginWriteTransaction];
        object.value = theValue;
        [realm commitWriteTransaction];
    }
}
@end

For simple testing, on button action I'm calling:
[KeyValue addValue:@"kz" forKey:@"lang"];
In Realm browser I see data I've just added. If I kill app and launch it again, data is on it's place. But, when I kill and relaunch app again, this time data is cleared. There is no script that clears the model, it just renews. Any ideas?

I can't reproduce this. Here's the sample project I used to attempt to trigger the behavior you're describing: GH3721.zip
Run 1
2016-06-07 11:13:53.365 GH3721[3212:259386] adding KeyValue object 'lang:kz'
2016-06-07 11:13:53.370 GH3721[3212:259386] all KeyValue objects: RLMResults <0x7fb820541c90> (
  [0] KeyValue {
    key = lang;
    value = kz;
  }
)

Run 2
2016-06-07 11:14:40.746 GH3721[3323:262587] all KeyValue objects: RLMResults <0x7ff63a79b260> (
  [0] KeyValue {
    key = lang;
    value = kz;
  }
)

Run 3
2016-06-07 11:14:54.288 GH3721[3346:263506] all KeyValue objects: RLMResults <0x7f9f08f61c90> (
  [0] KeyValue {
    key = lang;
    value = kz;
  }
)

Can you take a look and see what you're doing differently in your app that could cause this to happen there, but not in my sample? Maybe you forgot to share a step?

@jpsim Thank you for sharing time to help me with sample project. My fault, deep in the classes I've found the script which calls [realm deleteAllObjects]; Sorry....
Is there a method to enable realm transactions' logging? e.g. new record created in 'KeyValue', all objects in default realm deleted .... etc.

authors: jpsim mixdesign

repo: realm/realm-cocoa