only report backtraces with one event, remove info events

double check that we respect the :collect_backtraces config
because of the removal of the info events the tests needed a lot of
adjustment in the trace counts and indexes.
padrino and sinatra had their instrumentation in 2 files each, consolidated into one each
added :collect_backtraces and :enabled configs for Padrino and Sinatra

AO-9540 AO-10161
The backtrace can be with the entry or the exit but should only be in one.
You'll see both situations. Mainly because the SDK methods trace and start_trace will remove the backtrace if it was present at the entry event.

Bruce, thanks for all your questions.
I made a few improvements and it helps my confidence  when I have to explain things.
Commit with corrections coming soon.


SonarCloud analysis run on unstable branch has wrong New issues num

Refer: https://github.com/apache/kvrocks/runs/20889223274

Here are some clues.
The "new code" displayed on SonarCloud is based on the code from November 23rd. How can we adjust it?

https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/analysis-parameters/
Maybe we need to set sonar.newCode.referenceBranch?
We can consider the code from the last release version(now 2.7) to the newest commit as the new code.

Add PR #2147


some rudimentary docs for demonstration purposes.

Codecov Report

Merging #70 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #70   +/-   ##
=======================================
  Coverage   68.14%   68.14%
=======================================
  Files          23       23
  Lines         970      970
=======================================
  Hits          661      661
  Misses        309      309

Impacted Files
Coverage Δ

starfish/registration/_fourier_shift.py
100% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7321b0c...d18ecde. Read the comment docs.


bots: Improve virtual_fs bot coverage

Used sample_conversation and other commands to improve code coverage from 54% to 94%

Seems to not work for Python 3

@abhijeetkaur Are you still working on this?


Fix 1187 attempt3

Here is another fix for the really annoying #1187 bug. E.g
10 [ [ minor-gc split-slice ] [ drop ] recover ] times

doesn't crash. :) So the problem is that there may be uninitialized holes in the stacks. Which works fine until a ##peek instruction looks at a stack slot above the known height and causes a stack underflow. Then the GC code tries to trace all slots on the stacks and that crashes because of the uninitialized slots. It's the same kind of problem that the gc maps solves.
So I've added a step compiler pass called clear-uninitialized which finds ##peeks that can cause underflows and inserts ##replace-imm instructions preceding those to initialize the stack slots with dummy values. I also had to detach the normalize-height and schedule-instructions passes because the way they reordered the instructions caused to many uninitialized slots which caused to many ##replace-imm's to be inserted.
There is some overhead, but not to much I think. The mean size per word increases from 386 to 391 bytes on 32 bit and 459 to 460 on 64 bit.

You can see the effect of the pr:
USE: compiler.cfg.debugger
[ dup ] regs.

! Old code generation
...
=== Basic block #1

##inc-d 1
##peek RCX D 1
##replace RCX D 0
##branch

Successors: 2
...

! New code generation
...
=== Basic block #1

##peek RCX D 0
##inc-d 1
##replace RCX D 0
##branch

Successors: 2

Merged, let's see if everything still works. Thanks!


index.js doesnt run / Error('double colon in host identifier');

did you set the DB URL?
it's in here: https://github.com/lucamezzalira/hapijs-mongodb-example/blob/master/src/config/DBConfig.js


Reduce default iteration counts for the test_suites script to 2.

This should help with CI load and is probably also better for local
testing now that we have more tests and a single iteration takes a few
seconds instead of hundreds of ms.
Problem
Tests are starting to take a long time as we add more of them.
Change overview
Reduce iteration count to speed things up.
Testing
Ran script manually, observed only 2 iterations happen.

@msandstedt @saurabhst @woody-apple @LuDuda @Damian-Nordic @jepenven-silabs @jmartinez-silabs Please take a look?  Would be good to reduce the CI load a bit.


Ability to create an exclusive SpiBus

Some drivers require an implementation of SpiBus but esp-idf-hal only provides SpiDevices at the moment.
I'm looking into implementing this.

I was going to call this SpiBusDriver but it looks like the name is already taken. I think it makes sense to just rename the existing one since it's not particularly public.


Syfmony 4.1 + How to generate model

Hi All,
I have upgrade Symfony 3.4 ( Propel ORM ) to Symfony 4.1 (Propel ORM).
(1) Where i have to create schema.xml fille ?
(2) How to  generate models ?
Thanks
Parthiv Shah

Hi,

install Propel Bundle: composer require propel/propel-bundle 4.0@dev
create src\propel path and put your schema.xml there
in your config\packages directory, create your propel.yaml configuration file
Build your model via PropelBundle commands: bin/console propel:build

Good luck!

Thanks
Issue is fixed.
I have generated model in "Entity" folder and get below error.
Attempted to load class "ActivityLogQuery" from namespace "App\Controller\App\Entity".
Did you forget a "use" statement for "App\Entity\ActivityLogQuery"?
<database name="yoursource" defaultIdMethod="native" namespace="Entity">
<table name="activity_log" idMethod="native" phpName="ActivityLog">
    <column name="activity_log_id" phpName="ActivityLogId" type="INTEGER" primaryKey="true" autoIncrement="true" required="true"/>
    <column name="activity_type_id" phpName="ActivityTypeId" type="INTEGER" required="true" defaultValue="1"/>
</table>
</database>

Please help.
Thanks you so much for quick help.

Did you forget a "use" statement for "App\Entity\ActivityLogQuery"?
It's not a Propel issue: get a look in your controller.

Thanks you so much but i have added but still not working. Please check my controller code.
namespace App\Controller;

use Entity;
use Entity\Person;
use Entity\PersonQuery;

class PersonController extends AbstractController
{
	public function logincheckAction(Request $request) {
		$person = PersonQuery::create()->filterByEmail($email)->findOne();
	}
}

All Model generated in src->Entity , src->Entity->Base , src->Entity->map.
Thanks.

Ah, ok. If you use the composer Symfony project autoloader, it associates the directory src/Entity to App\Entity namespace.
So change the first line of your schema.xml as follow;
<database name="yoursource" defaultIdMethod="native" namespace="App\Entity">
and rebuild your model.
Now, in your controllers write:
namespace App\Controller;

use App\Entity\Person;
use App\Entity\PersonQuery;

class PersonController extends AbstractController
{
	public function logincheckAction(Request $request) {
		$person = PersonQuery::create()->filterByEmail($email)->findOne();
	}
}

Tip: since the directory src/Entity is used by Doctrine, I prefer to put Propel classes in src/Model path.
To do it, just write (in your schema.xml): <database name="yoursource" defaultIdMethod="native" namespace="App\Model"> and rebuild your model. Propel creates for you the directory and the classes.

Thanks you so much.Now issue is fixed.


better pagination and a simple judgment

problems' pagination was implemented in a more concise way, and the contests list was processed in the same way (I think it would be necessary), adding the judgment of whether or not there was a contest when opening the contests page.

Realize the gap, learn from this pr


renderer attribute is ignored when supering original "render" method on widget

This is a WidgetMixin's render method:
    def render(self, name, value, attrs=None, renderer=None, **kwargs):
        """Call Django render together with `render_forward_conf`."""
        widget = super(WidgetMixin, self).render(name, value, attrs, **kwargs)
        try:
            field_id = attrs['id']
        except (KeyError, TypeError):
            field_id = name
        conf = self.render_forward_conf(field_id)
        return mark_safe(widget + conf)

When invoking "render" method the "renderer" is ignored - why? If project is configured for using a different form renderer (for ex. https://docs.djangoproject.com/en/3.2/ref/forms/renderers/#templatessetting) it ruins everything because then it uses a default DjangoTemplate renderer which is not ok.

Support for other renderers would be nice to see in a PR


Use the  component

frameworks have become smaller, bundlers have become more efficient...
frameworks have become smaller, bundlers have become more efficient. Is this exactly true, and is it more effective? 2024, I can't do something like this
UIIImage  :image-name="example.png"
and on the output get an image with srcset or picture?
can I use images dynamically?
no one does it like in your example - import in advance into the addresses component..
please provide example for
Image :name="example.png"
..in Image
optionsDefault = {
src: ?
srcset ?
return Image :src="?" :srcset="?"

This is a low-level package meant to be used to help build such components. E.g. Svelte's enhanced:img is built on vite-imagetools: https://kit.svelte.dev/docs/images#sveltejs-enhanced-img

thanks for the answer


not in asn1Spec: TagMap() when using version > 0.2.3

Hi!
I'm using pyasn1 in androguard to parse X509 certificates. I noticed that travis uses now Version 0.3.2 of pyasn1 and the decoding of the DER encoded file throws an exception. This was not the case in Version 0.2.3. where everything worked just fine.
Here is a short programm to test it:
import binascii
from pyasn1.codec.der.decoder import decode

certhex  = b"3082039506092a864886f70d010702a082038630820382020101310b300906052b0e03021a0500300b06092a864886f70d010701a08202d0308202cc30820289a003020102020466eda548300b06072a8648ce380403050030363110300e06035504061307736961766173683110300e060355040a1307736961766173683110300e06035504031307736961766173683020170d3136303132353037323533305a180f32303534303532353037323533305a30363110300e06035504061307736961766173683110300e060355040a1307736961766173683110300e0603550403130773696176617368308201b83082012c06072a8648ce3804013082011f02818100fd7f53811d75122952df4a9c2eece4e7f611b7523cef4400c31e3f80b6512669455d402251fb593d8d58fabfc5f5ba30f6cb9b556cd7813b801d346ff26660b76b9950a5a49f9fe8047b1022c24fbba9d7feb7c61bf83b57e7c6a8a6150f04fb83f6d3c51ec3023554135a169132f675f3ae2b61d72aeff22203199dd14801c70215009760508f15230bccb292b982a2eb840bf0581cf502818100f7e1a085d69b3ddecbbcab5c36b857b97994afbbfa3aea82f9574c0b3d0782675159578ebad4594fe67107108180b449167123e84c281613b7cf09328cc8a6e13c167a8b547c8d28e0a3ae1e2bb3a675916ea37f0bfa213562f1fb627a01243bcca4f1bea8519089a883dfe15ae59f06928b665e807b552564014c3bfecf492a0381850002818100e9b46a500aabcbb7b42e93477db9f8ac7c819eadd392f4fa2dd7c10973c399d00d45796052bfb376567a518cfe1432a0f845e4be75aa76462335bf7f84b6c634bb6c884b6ae2e7b6f1cc78c3be6f98b65980832c40d9da3d2b047cba98b24c877b2ace7908b0af56fd62367df355e011a0482c9b8751c373a8d131076cd01421a321301f301d0603551d0e04160414eeac32e5f08781bb6f2f392814951b328868ae4c300b06072a8648ce3804030500033000302d0215009209eb12e966aafae281620e7da9743774d7846302144bf36a9634967ca47639bbc10712571b036e13d531818e30818b020101303e30363110300e06035504061307736961766173683110300e060355040a1307736961766173683110300e0603550403130773696176617368020466eda548300906052b0e03021a0500300b06072a8648ce3804010500042e302c02145de23a86f0c2e45dcad93ef8cab675ec56a6ff4b021404c1a9f7f791631ae00d61fe8ae23f502c33fe84"

pkcs7message = binascii.unhexlify(certhex)

message, _ = decode(pkcs7message)

Traceback (most recent call last):
  File "D:\bla.py", line 8, in <module>
    message, _ = decode(pkcs7message)
  File "C:\Program Files\Anaconda3\lib\site-packages\pyasn1\codec\ber\decoder.py", line 1008, in __call__
    stGetValueDecoder, self, substrateFun
  File "C:\Program Files\Anaconda3\lib\site-packages\pyasn1\codec\ber\decoder.py", line 382, in valueDecoder
    component, head = decodeFun(head, asn1Spec)
  File "C:\Program Files\Anaconda3\lib\site-packages\pyasn1\codec\ber\decoder.py", line 1008, in __call__
    stGetValueDecoder, self, substrateFun
  File "C:\Program Files\Anaconda3\lib\site-packages\pyasn1\codec\ber\decoder.py", line 71, in valueDecoder
    value, _ = decodeFun(head, asn1Spec, tagSet, length)
  File "C:\Program Files\Anaconda3\lib\site-packages\pyasn1\codec\ber\decoder.py", line 1008, in __call__
    stGetValueDecoder, self, substrateFun
  File "C:\Program Files\Anaconda3\lib\site-packages\pyasn1\codec\ber\decoder.py", line 382, in valueDecoder
    component, head = decodeFun(head, asn1Spec)
  File "C:\Program Files\Anaconda3\lib\site-packages\pyasn1\codec\ber\decoder.py", line 1008, in __call__
    stGetValueDecoder, self, substrateFun
  File "C:\Program Files\Anaconda3\lib\site-packages\pyasn1\codec\ber\decoder.py", line 382, in valueDecoder
    component, head = decodeFun(head, asn1Spec)
  File "C:\Program Files\Anaconda3\lib\site-packages\pyasn1\codec\ber\decoder.py", line 1015, in __call__
    '%s not in asn1Spec: %r' % (tagSet, asn1Spec)
pyasn1.error.PyAsn1Error: [0:32:16] not in asn1Spec: TagMap()

using the old version (<= 0.2.3 and I tested up to 0.1.8) everything works,
I tried to understand the problem and read the changelog but I can not see anything obvious there.
I read in the documentation, that you can give the decoder an asn1Spec but until now it worked without it.
Because the behavior of the function changed without any note in the changelog, I suspect this is actually a bug.

ah sorry, I saw this is already fixed...
I looked around for the error message quite extensivly but of course not in the issue tracker :(

The fixed version is going to be released (as 0.3.3) by the end of the week. If you still experience any issues with the current master, please let me know ASAP.
Thanks! ;-)

that should remind me to look at the closed tickets as well ;)
I tested it with the master and it works fine!


Schedule list with query times out on server 1.25.0-rc.0

Upgrading the server in the Go SDK test suite, causes a test that lists schedules with a visibility query to time out.
https://github.com/temporalio/sdk-go/commit/1350fb4bd58fa0782c774ab198d75e8cafb1fcff#diff-8118e44ac15fb5ab2e2ece2ab52fd23062a10b5cc9c55ee5b3620a1242cff27cR4938

Thanks for reporting the issue.  The provided code snippet references the commit that introduced the change:
https://github.com/temporalio/sdk-go/commit/1350fb4bd58fa0782c774ab198d75e8cafb1fcff#diff-8118e44ac15fb5ab2e2ece2ab52fd23062a10b5cc9c55ee5b3620a1242cff27cR4938

Can you tell me more about the visibility query being used in the test case?  Specifically, what are the query parameters being passed?  This will help identify potential causes for the timeout.


[24.12.15] [BUG] (or not ?) duplicat hydro

maraxsis_1.23.46

Facotrio Version: 2.0.25

in upgrade planner i see 2 same icone of  hydro factory, why 2 ?

one with 4 slot of module

and one with 6 slot of modules

Thanks for the report. The hydro plant with extra module slots is used in the trench. There are actually two hydro plant prototypes.
The upgrade planner must show both in order to allow the user to upgrade hydro plants from within the trench. For this reason I believe this report can be marked as not a bug.

maybe rename the second on "MKII" or "ADV"
and add a description like "in trench, it's better" for the MKI


suspender failed to resume the scan after beam recovered from beam dump

beam dumped around 10:30 pm and came back around 10:50 pm.
suspender successfully paused the scan but failed to resume the scan.
This was the scan:
BlueSky [29]: gs.RE(hf2dxrf(xstart = 29.3091, xnumstep=105, xstepsize=0.005, ystart = 26.3144, ynumstep=94, ystepsize = 0.005, acqtime=0.3, numrois =3))

errors seen below:
+-----------+------------+------------+--------------------------+------------+--------------------------+--------------------+--------------------+------------------------------+------------------------------+------------------------------+
|   seq_num |       time | hf_stage_x | hf_stage_x_user_setpoint | hf_stage_y | hf_stage_y_user_setpoint | current_preamp_ch0 | current_preamp_ch2 | xs_channel1_rois_roi01_value | xs_channel1_rois_roi02_value | xs_channel1_rois_roi03_value |
+-----------+------------+------------+--------------------------+------------+--------------------------+--------------------+--------------------+------------------------------+------------------------------+------------------------------+
|      4901 | 22:29:02.7 |  29.429110 |                29.429110 |  26.544395 |                26.544360 |        0.000000102 |       -0.000000099 |                     122.8359 |                    1463.8787 |                      67.0014 |
|      4902 | 22:29:03.6 |  29.434095 |                29.434100 |  26.544375 |                26.544385 |        0.000000102 |       -0.000000099 |                     110.4572 |                     775.2271 |                      73.9759 |
|      4903 | 22:29:04.4 |  29.439095 |                29.439100 |  26.544400 |                26.544385 |        0.000000098 |       -0.000000099 |                     105.3212 |                     540.7841 |                     107.3467 |
|      4904 | 22:29:05.4 |  29.444095 |                29.444100 |  26.544420 |                26.544385 |        0.000000099 |       -0.000000099 |                      98.1393 |                     341.9700 |                      64.7517 |
|      4905 | 22:29:06.1 |  29.449115 |                29.449100 |  26.544385 |                26.544385 |        0.000000102 |       -0.000000099 |                      80.9072 |                     333.7422 |                      49.5557 |
|      4906 | 22:29:06.9 |  29.454110 |                29.454100 |  26.544375 |                26.544375 |        0.000000102 |       -0.000000099 |                      74.8096 |                     282.0525 |                      50.5470 |
|      4907 | 22:29:07.9 |  29.459100 |                29.459100 |  26.544420 |                26.544375 |        0.000000102 |       -0.000000099 |                      74.7951 |                     341.6317 |                      46.4943 |
|      4908 | 22:29:08.8 |  29.464105 |                29.464100 |  26.544400 |                26.544375 |        0.000000102 |       -0.000000099 |                      69.7352 |                     236.4933 |                      62.6606 |
|      4909 | 22:29:09.7 |  29.469075 |                29.469075 |  26.544365 |                26.544375 |        0.000000102 |       -0.000000099 |                      74.7701 |                     182.8836 |                      58.6036 |
|      4910 | 22:29:10.6 |  29.474105 |                29.474100 |  26.544400 |                26.544375 |        0.000000101 |       -0.000000039 |                       0.0000 |                       0.0000 |                       0.0000 |
Suspending....To get prompt hit Ctrl-C twice to pause.
Justification for this suspension:
Signal ring_current = 0.0 is below 200
Suspending....To get prompt hit Ctrl-C twice to pause.
Justification for this suspension:
Signal shut_fe_close_status is high
Still capturing data .... waiting.
Still capturing data .... waiting.
Still capturing data .... waiting.
Still capturing data .... giving up.
---------------------------------------------------------------------------
IllegalMessageSequence                    Traceback (most recent call last)
<ipython-input-28-bec8f2330b9d> in <module>()
----> 1 gs.RE(hf2dxrf(xstart = 29.3091, xnumstep=105, xstepsize=0.005, ystart = 26.3144, ynumstep=94, ystepsize = 0.005, acqtime=0.3, numrois =3))

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in __call__(self, plan, subs, raise_if_interrupted, **metadata_kw)
    601                 exc = self._task.exception()
    602                 if exc is not None:
--> 603                     raise exc
    604             if raise_if_interrupted and self._interrupted:
    605                 raise RunEngineInterrupted("RunEngine was interrupted.")

/home/xf05id1/conda_envs/collection/lib/python3.4/asyncio/tasks.py in _step(***failed resolving arguments***)
    237                 # We use the `send` method directly, because coroutines
    238                 # don't have `__iter__` and `__next__` methods.
--> 239                 result = coro.send(None)
    240             else:
    241                 result = coro.throw(exc)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _run(self)
    982             self.log.error("Run aborted")
    983             self.log.error("%r", err)
--> 984             raise err
    985         finally:
    986             # call stop() on every movable object we ever set()

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _run(self)
    880                         resp = self._response_stack.pop()
    881                         try:
--> 882                             msg = self._plan_stack[-1].send(resp)
    883                         # We have exhausted the top generator
    884                         except StopIteration:

/nfs/xf05id1/ipython_ophyd/profile_xf05id1/startup/91-xrfsetup.py in hf2dxrf(xstart, xnumstep, xstepsize, ystart, ynumstep, ystepsize, acqtime, numrois, i0map_show, itmap_show, energy, u_detune)
    194     hf2dxrf_scanplan = OuterProductAbsScanPlan(det, hf_stage.y, ystart, ystop, ynumstep+1, hf_stage.x, xstart, xstop, xnumstep+1, True, md=md)
    195     hf2dxrf_scanplan = bp.subs_wrapper( hf2dxrf_scanplan, livecallbacks)
--> 196     scaninfo = yield from hf2dxrf_scanplan
    197
    198     #TO-DO: implement fast shutter control (close)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in subs_wrapper(plan, subs)
    851
    852     return (yield from finalize_wrapper(pchain(_subscribe(), plan),
--> 853                                         _unsubscribe()))
    854
    855

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in finalize_wrapper(plan, final_plan)
    939     cleanup = True
    940     try:
--> 941         ret = yield from plan
    942     except GeneratorExit:
    943         cleanup = False

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in pchain(*args)
    257     rets = deque()
    258     for p in args:
--> 259         rets.append((yield from p))
    260     return tuple(rets)
    261

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in cls_plan()
   2878
   2879                 for gen in plan_stack:
-> 2880                     yield from gen
   2881             finally:
   2882                 for key, val in current_settings.items():

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in fly_during_wrapper(plan, flyers)
   1240     plan1 = plan_mutator(plan, insert_after_open)
   1241     plan2 = plan_mutator(plan1, insert_before_close)
-> 1242     return (yield from plan2)
   1243
   1244

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    164                 continue
    165             else:
--> 166                 raise ex
    167
    168         # if inserting / mutating, put new generator on the stack

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    120             # send last result to the top most generator in the
    121             # stack this may raise StopIteration
--> 122             msg = plan_stack[-1].send(ret)
    123
    124         except StopIteration:

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    164                 continue
    165             else:
--> 166                 raise ex
    167
    168         # if inserting / mutating, put new generator on the stack

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    120             # send last result to the top most generator in the
    121             # stack this may raise StopIteration
--> 122             msg = plan_stack[-1].send(ret)
    123
    124         except StopIteration:

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in wrapped(*args, **kwargs)
     69         gen_stack = func(*args, **kwargs)
     70         for g in gen_stack:
---> 71             yield from g
     72
     73     return wrapped

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in wrapped(*args, **kwargs)
     69         gen_stack = func(*args, **kwargs)
     70         for g in gen_stack:
---> 71             yield from g
     72
     73     return wrapped

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in wrapped(*args, **kwargs)
     69         gen_stack = func(*args, **kwargs)
     70         for g in gen_stack:
---> 71             yield from g
     72
     73     return wrapped

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in trigger_and_read(devices, name)
   1631             plan_stack.append(single_gen(Msg('read', obj)))
   1632
-> 1633     return (yield from rewindable_wrapper(pchain(*plan_stack), rewindable))
   1634
   1635

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in rewindable_wrapper(plan, rewindable)
   1078         yield from set_rewindable(rewindable)
   1079         return (yield from finalize_wrapper(plan,
-> 1080                                             restore_rewindable()))
   1081     else:
   1082         return (yield from plan)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in finalize_wrapper(plan, final_plan)
    939     cleanup = True
    940     try:
--> 941         ret = yield from plan
    942     except GeneratorExit:
    943         cleanup = False

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in pchain(*args)
    257     rets = deque()
    258     for p in args:
--> 259         rets.append((yield from p))
    260     return tuple(rets)
    261

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/utils.py in single_gen(msg)
    115         the input message
    116     '''
--> 117     yield msg
    118
    119

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    190         try:
    191             # yield out the 'current message' and collect the return
--> 192             inner_ret = yield msg
    193         except Exception as ex:
    194             msg = plan.throw(ex)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    190         try:
    191             # yield out the 'current message' and collect the return
--> 192             inner_ret = yield msg
    193         except Exception as ex:
    194             msg = plan.throw(ex)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _run(self)
    931                         # exceptions (coming in via throw) can be
    932                         # raised
--> 933                         response = yield from coro(msg)
    934                     # special case `CancelledError` and let the outer
    935                     # exception block deal with it.

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _save(self, msg)
   1375         """
   1376         if not self._bundling:
-> 1377             raise IllegalMessageSequence("A 'create' message must be sent, to "
   1378                                          "open an event bundle, before that "
   1379                                          "bundle can be saved with 'save'.")

IllegalMessageSequence: A 'create' message must be sent, to open an event bundle, before that bundle can be saved with 'save'.

I noticed this bug in the code today and discribed it as 'a rare and unlikely edge case' :disappointed:
Will try to have a fix in on the train tomorrow.

a rare and unlikely edge case

:smile:

Around 2:25 last night, the suspender due to cryo cooler refilling successfully paused the scan, but also failed to resume the scan. See trace back below; seems to be the same error message.
Not sure if this information helps but FYI.
-----------+------------+------------+--------------------------+------------+--------------------------+--------------------+--------------------+------------------------------+------------------------------+
|   seq_num |       time | hf_stage_x | hf_stage_x_user_setpoint | hf_stage_y | hf_stage_y_user_setpoint | current_preamp_ch0 | current_preamp_ch2 | xs_channel1_rois_roi01_value | xs_channel1_rois_roi02_value |
+-----------+------------+------------+--------------------------+------------+--------------------------+--------------------+--------------------+------------------------------+------------------------------+
|       800 | 02:25:12.5 |  29.549120 |                29.549100 |  26.349380 |                26.349380 |        0.000000553 |       -0.000000003 |                   64218.1508 |                      65.5684 |
|       801 | 02:25:13.3 |  29.544085 |                29.544100 |  26.349375 |                26.349400 |        0.000000565 |       -0.000000003 |                   52252.5965 |                      68.7793 |
Suspending....To get prompt hit Ctrl-C twice to pause.
Justification for this suspension:
Signal cryo_v19 = 1.0 is above 0.8
/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py:1976: UserWarning: A KeyError('xs_channel1_rois_roi02_value',) was raised during the processing of a event Document. The error will be ignored to avoid interrupting data collection. To investigate, set RunEngine.ignore_callback_exceptions = False and run again.
  "and run again." % (exc, name.name))
/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py:1976: UserWarning: A KeyError('xs_channel1_rois_roi01_value',) was raised during the processing of a event Document. The error will be ignored to avoid interrupting data collection. To investigate, set RunEngine.ignore_callback_exceptions = False and run again.
  "and run again." % (exc, name.name))
/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py:1976: UserWarning: A KeyError('current_preamp_ch2',) was raised during the processing of a event Document. The error will be ignored to avoid interrupting data collection. To investigate, set RunEngine.ignore_callback_exceptions = False and run again.
  "and run again." % (exc, name.name))
Still capturing data .... waiting.
Still capturing data .... waiting.
Still capturing data .... waiting.
Still capturing data .... giving up.
---------------------------------------------------------------------------
IllegalMessageSequence                    Traceback (most recent call last)
/nfs/xf05id1/userdata/2016_cycle2/300441_Chen-Wiegart-METCourbet/overnightscript.ipy in <module>()
     13 energy.move(14)
     14 time.sleep(60*5)
---> 15 gs.RE(hf2dxrf(xstart = 29.3091, xnumstep=105, xstepsize=0.005, ystart = 26.3144, ynumstep=94, ystepsize = 0.005, acqtime=0.3, numrois =2))
     16 energy.move_u_gap.set(True)
     17 #linelist=[[29.3395+i*0.025,26.5335] for i in range(18)]

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in __call__(self, plan, subs, raise_if_interrupted, **metadata_kw)
    601                 exc = self._task.exception()
    602                 if exc is not None:
--> 603                     raise exc
    604             if raise_if_interrupted and self._interrupted:
    605                 raise RunEngineInterrupted("RunEngine was interrupted.")

/home/xf05id1/conda_envs/collection/lib/python3.4/asyncio/tasks.py in _step(***failed resolving arguments***)
    237                 # We use the `send` method directly, because coroutines
    238                 # don't have `__iter__` and `__next__` methods.
--> 239                 result = coro.send(None)
    240             else:
    241                 result = coro.throw(exc)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _run(self)
    982             self.log.error("Run aborted")
    983             self.log.error("%r", err)
--> 984             raise err
    985         finally:
    986             # call stop() on every movable object we ever set()

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _run(self)
    880                         resp = self._response_stack.pop()
    881                         try:
--> 882                             msg = self._plan_stack[-1].send(resp)
    883                         # We have exhausted the top generator
    884                         except StopIteration:

/nfs/xf05id1/userdata/2016_cycle2/300441_Chen-Wiegart-METCourbet/overnightscript.ipy in hf2dxrf(xstart, xnumstep, xstepsize, ystart, ynumstep, ystepsize, acqtime, numrois, i0map_show, itmap_show, energy, u_detune)
    194     hf2dxrf_scanplan = OuterProductAbsScanPlan(det, hf_stage.y, ystart, ystop, ynumstep+1, hf_stage.x, xstart, xstop, xnumstep+1, True, md=md)
    195     hf2dxrf_scanplan = bp.subs_wrapper( hf2dxrf_scanplan, livecallbacks)
--> 196     scaninfo = yield from hf2dxrf_scanplan
    197
    198     #TO-DO: implement fast shutter control (close)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in subs_wrapper(plan, subs)
    851
    852     return (yield from finalize_wrapper(pchain(_subscribe(), plan),
--> 853                                         _unsubscribe()))
    854
    855

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in finalize_wrapper(plan, final_plan)
    939     cleanup = True
    940     try:
--> 941         ret = yield from plan
    942     except GeneratorExit:
    943         cleanup = False

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in pchain(*args)
    257     rets = deque()
    258     for p in args:
--> 259         rets.append((yield from p))
    260     return tuple(rets)
    261

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in cls_plan()
   2878
   2879                 for gen in plan_stack:
-> 2880                     yield from gen
   2881             finally:
   2882                 for key, val in current_settings.items():

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in fly_during_wrapper(plan, flyers)
   1240     plan1 = plan_mutator(plan, insert_after_open)
   1241     plan2 = plan_mutator(plan1, insert_before_close)
-> 1242     return (yield from plan2)
   1243
   1244

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    164                 continue
    165             else:
--> 166                 raise ex
    167
    168         # if inserting / mutating, put new generator on the stack

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    120             # send last result to the top most generator in the
    121             # stack this may raise StopIteration
--> 122             msg = plan_stack[-1].send(ret)
    123
    124         except StopIteration:

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    164                 continue
    165             else:
--> 166                 raise ex
    167
    168         # if inserting / mutating, put new generator on the stack

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    120             # send last result to the top most generator in the
    121             # stack this may raise StopIteration
--> 122             msg = plan_stack[-1].send(ret)
    123
    124         except StopIteration:

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in wrapped(*args, **kwargs)
     69         gen_stack = func(*args, **kwargs)
     70         for g in gen_stack:
---> 71             yield from g
     72
     73     return wrapped

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in wrapped(*args, **kwargs)
     69         gen_stack = func(*args, **kwargs)
     70         for g in gen_stack:
---> 71             yield from g
     72
     73     return wrapped

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in wrapped(*args, **kwargs)
     69         gen_stack = func(*args, **kwargs)
     70         for g in gen_stack:
---> 71             yield from g
     72
     73     return wrapped

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in trigger_and_read(devices, name)
   1631             plan_stack.append(single_gen(Msg('read', obj)))
   1632
-> 1633     return (yield from rewindable_wrapper(pchain(*plan_stack), rewindable))
   1634
   1635

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in rewindable_wrapper(plan, rewindable)
   1078         yield from set_rewindable(rewindable)
   1079         return (yield from finalize_wrapper(plan,
-> 1080                                             restore_rewindable()))
   1081     else:
   1082         return (yield from plan)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in finalize_wrapper(plan, final_plan)
    939     cleanup = True
    940     try:
--> 941         ret = yield from plan
    942     except GeneratorExit:
    943         cleanup = False

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in pchain(*args)
    257     rets = deque()
    258     for p in args:
--> 259         rets.append((yield from p))
    260     return tuple(rets)
    261

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/utils.py in single_gen(msg)
    115         the input message
    116     '''
--> 117     yield msg
    118
    119

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    190         try:
    191             # yield out the 'current message' and collect the return
--> 192             inner_ret = yield msg
    193         except Exception as ex:
    194             msg = plan.throw(ex)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    190         try:
    191             # yield out the 'current message' and collect the return
--> 192             inner_ret = yield msg
    193         except Exception as ex:
    194             msg = plan.throw(ex)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _run(self)
    931                         # exceptions (coming in via throw) can be
    932                         # raised
--> 933                         response = yield from coro(msg)
    934                     # special case `CancelledError` and let the outer
    935                     # exception block deal with it.

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _save(self, msg)
   1375         """
   1376         if not self._bundling:
-> 1377             raise IllegalMessageSequence("A 'create' message must be sent, to "
   1378                                          "open an event bundle, before that "
   1379                                          "bundle can be saved with 'save'.")

IllegalMessageSequence: A 'create' message must be sent, to open an event bundle, before that bundle can be saved with 'save'.

Thanks, it does help.

ok, another (same) error from cryo-cooler refill suspender. It seems to be reproducible.
+-----------+------------+------------+--------------------------+------------+--------------------------+--------------------+--------------------+------------------------------+
|   seq_num |       time | hf_stage_x | hf_stage_x_user_setpoint | hf_stage_y | hf_stage_y_user_setpoint | current_preamp_ch0 | current_preamp_ch2 | xs_channel1_rois_roi01_value |
+-----------+------------+------------+--------------------------+------------+--------------------------+--------------------+--------------------+------------------------------+
|       100 | 11:15:11.7 |  31.191985 |                31.192000 |  20.960000 |                20.960000 |        0.000040032 |       -0.000000020 |                    1205.0315 |
|       101 | 11:15:12.7 |  31.171995 |                31.172000 |  20.960000 |                20.960000 |        0.000040068 |       -0.000000020 |                    1214.8528 |
|       102 | 11:15:13.7 |  31.151995 |                31.152000 |  20.960000 |                20.960000 |        0.000039956 |       -0.000000020 |                    1271.8692 |
|       103 | 11:15:14.7 |  31.132000 |                31.132000 |  20.960000 |                20.960000 |        0.000039743 |       -0.000000020 |                    1214.3424 |
|       104 | 11:15:15.7 |  31.112010 |                31.112000 |  20.960000 |                20.960000 |        0.000039821 |       -0.000000020 |                    1156.7435 |
|       105 | 11:15:17.9 |  31.111985 |                31.112000 |  20.979995 |                20.980000 |        0.000039778 |       -0.000000020 |                    1236.9660 |
|       106 | 11:15:18.9 |  31.131995 |                31.132000 |  20.980000 |                20.980000 |        0.000039818 |       -0.000000020 |                    1298.6791 |
|       107 | 11:15:19.9 |  31.151995 |                31.152000 |  20.980000 |                20.980000 |        0.000039844 |       -0.000000020 |                    1281.2595 |
|       108 | 11:15:20.9 |  31.171990 |                31.172000 |  20.979995 |                20.980000 |        0.000039763 |       -0.000000020 |                    1190.3261 |
|       109 | 11:15:21.9 |  31.192000 |                31.192000 |  20.980000 |                20.980000 |        0.000039900 |       -0.000000020 |                    1231.2811 |
|       110 | 11:15:23.0 |  31.211990 |                31.212000 |  20.980010 |                20.980000 |        0.000039962 |       -0.000000020 |                    1226.5022 |
Suspending....To get prompt hit Ctrl-C twice to pause.
Justification for this suspension:
Signal cryo_v19 = 1.0 is above 0.8
/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py:1976: UserWarning: A KeyError('current_preamp_ch2',) was raised during the processing of a event Document. The error will be ignored to avoid interrupting data collection. To investigate, set RunEngine.ignore_callback_exceptions = False and run again.
  "and run again." % (exc, name.name))
/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py:1976: UserWarning: A KeyError('xs_channel1_rois_roi01_value',) was raised during the processing of a event Document. The error will be ignored to avoid interrupting data collection. To investigate, set RunEngine.ignore_callback_exceptions = False and run again.
  "and run again." % (exc, name.name))
Still capturing data .... waiting.
Still capturing data .... waiting.
Still capturing data .... waiting.
Still capturing data .... giving up.
---------------------------------------------------------------------------
IllegalMessageSequence                    Traceback (most recent call last)
<ipython-input-22-2efa77023a7b> in <module>()
----> 1 gs.RE(hf2dxrf(xstart = 31.112, xnumstep=25, xstepsize=0.02, ystart = 20.9, ynumstep=25, ystepsize = 0.02, acqtime=0.5, numrois =1))

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in __call__(self, plan, subs, raise_if_interrupted, **metadata_kw)
    601                 exc = self._task.exception()
    602                 if exc is not None:
--> 603                     raise exc
    604             if raise_if_interrupted and self._interrupted:
    605                 raise RunEngineInterrupted("RunEngine was interrupted.")

/home/xf05id1/conda_envs/collection/lib/python3.4/asyncio/tasks.py in _step(***failed resolving arguments***)
    237                 # We use the `send` method directly, because coroutines
    238                 # don't have `__iter__` and `__next__` methods.
--> 239                 result = coro.send(None)
    240             else:
    241                 result = coro.throw(exc)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _run(self)
    982             self.log.error("Run aborted")
    983             self.log.error("%r", err)
--> 984             raise err
    985         finally:
    986             # call stop() on every movable object we ever set()

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _run(self)
    880                         resp = self._response_stack.pop()
    881                         try:
--> 882                             msg = self._plan_stack[-1].send(resp)
    883                         # We have exhausted the top generator
    884                         except StopIteration:

/nfs/xf05id1/ipython_ophyd/profile_xf05id1/startup/91-xrfsetup.py in hf2dxrf(xstart, xnumstep, xstepsize, ystart, ynumstep, ystepsize, acqtime, numrois, i0map_show, itmap_show, energy, u_detune)
    194     hf2dxrf_scanplan = OuterProductAbsScanPlan(det, hf_stage.y, ystart, ystop, ynumstep+1, hf_stage.x, xstart, xstop, xnumstep+1, True, md=md)
    195     hf2dxrf_scanplan = bp.subs_wrapper( hf2dxrf_scanplan, livecallbacks)
--> 196     scaninfo = yield from hf2dxrf_scanplan
    197
    198     #TO-DO: implement fast shutter control (close)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in subs_wrapper(plan, subs)
    851
    852     return (yield from finalize_wrapper(pchain(_subscribe(), plan),
--> 853                                         _unsubscribe()))
    854
    855

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in finalize_wrapper(plan, final_plan)
    939     cleanup = True
    940     try:
--> 941         ret = yield from plan
    942     except GeneratorExit:
    943         cleanup = False

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in pchain(*args)
    257     rets = deque()
    258     for p in args:
--> 259         rets.append((yield from p))
    260     return tuple(rets)
    261

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in cls_plan()
   2878
   2879                 for gen in plan_stack:
-> 2880                     yield from gen
   2881             finally:
   2882                 for key, val in current_settings.items():

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in fly_during_wrapper(plan, flyers)
   1240     plan1 = plan_mutator(plan, insert_after_open)
   1241     plan2 = plan_mutator(plan1, insert_before_close)
-> 1242     return (yield from plan2)
   1243
   1244

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    164                 continue
    165             else:
--> 166                 raise ex
    167
    168         # if inserting / mutating, put new generator on the stack

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    120             # send last result to the top most generator in the
    121             # stack this may raise StopIteration
--> 122             msg = plan_stack[-1].send(ret)
    123
    124         except StopIteration:

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    164                 continue
    165             else:
--> 166                 raise ex
    167
    168         # if inserting / mutating, put new generator on the stack

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    120             # send last result to the top most generator in the
    121             # stack this may raise StopIteration
--> 122             msg = plan_stack[-1].send(ret)
    123
    124         except StopIteration:

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in wrapped(*args, **kwargs)
     69         gen_stack = func(*args, **kwargs)
     70         for g in gen_stack:
---> 71             yield from g
     72
     73     return wrapped

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in wrapped(*args, **kwargs)
     69         gen_stack = func(*args, **kwargs)
     70         for g in gen_stack:
---> 71             yield from g
     72
     73     return wrapped

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in wrapped(*args, **kwargs)
     69         gen_stack = func(*args, **kwargs)
     70         for g in gen_stack:
---> 71             yield from g
     72
     73     return wrapped

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in trigger_and_read(devices, name)
   1631             plan_stack.append(single_gen(Msg('read', obj)))
   1632
-> 1633     return (yield from rewindable_wrapper(pchain(*plan_stack), rewindable))
   1634
   1635

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in rewindable_wrapper(plan, rewindable)
   1078         yield from set_rewindable(rewindable)
   1079         return (yield from finalize_wrapper(plan,
-> 1080                                             restore_rewindable()))
   1081     else:
   1082         return (yield from plan)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in finalize_wrapper(plan, final_plan)
    939     cleanup = True
    940     try:
--> 941         ret = yield from plan
    942     except GeneratorExit:
    943         cleanup = False

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in pchain(*args)
    257     rets = deque()
    258     for p in args:
--> 259         rets.append((yield from p))
    260     return tuple(rets)
    261

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/utils.py in single_gen(msg)
    115         the input message
    116     '''
--> 117     yield msg
    118
    119

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    190         try:
    191             # yield out the 'current message' and collect the return
--> 192             inner_ret = yield msg
    193         except Exception as ex:
    194             msg = plan.throw(ex)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/plans.py in plan_mutator(plan, msg_proc)
    190         try:
    191             # yield out the 'current message' and collect the return
--> 192             inner_ret = yield msg
    193         except Exception as ex:
    194             msg = plan.throw(ex)

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _run(self)
    931                         # exceptions (coming in via throw) can be
    932                         # raised
--> 933                         response = yield from coro(msg)
    934                     # special case `CancelledError` and let the outer
    935                     # exception block deal with it.

/home/xf05id1/conda_envs/collection/lib/python3.4/site-packages/bluesky/run_engine.py in _save(self, msg)
   1375         """
   1376         if not self._bundling:
-> 1377             raise IllegalMessageSequence("A 'create' message must be sent, to "
   1378                                          "open an event bundle, before that "
   1379                                          "bundle can be saved with 'save'.")

IllegalMessageSequence: A 'create' message must be sent, to open an event bundle, before that bundle can be saved with 'save'.

giff --git a/bluesky/run_engine.py b/bluesky/run_engine.py
index d3228ac..9069803 100644
--- a/bluesky/run_engine.py
+++ b/bluesky/run_engine.py
@@ -644,14 +644,16 @@ class RunEngine:
              A new plan made from the messages in the message cache

         '''
+        len_msg_cache = len(self._msg_cache)
         new_plan = ensure_generator(list(self._msg_cache))
         self._msg_cache = deque()
-        self._sequence_counters.clear()
-        self._sequence_counters.update(self._teed_sequence_counters)
-        # This is needed to 'cancel' an open bundling (e.g. create) if
-        # the pause happens after a 'checkpoint', after a 'create', but before
-        # the paired 'save'.
-        self._bundling = False
+        if len_msg_cache:
+            self._sequence_counters.clear()
+            self._sequence_counters.update(self._teed_sequence_counters)
+            # This is needed to 'cancel' an open bundling (e.g. create) if
+            # the pause happens after a 'checkpoint', after a 'create', but before
+            # the paired 'save'.
+            self._bundling = False
         return new_plan

     def _resume_event_loop(self):

This should hot fix it, but is untested
@danielballan @klauer can one if you take care of this?

https://github.com/NSLS-II/bluesky/pull/534

Merged, but can (or should) we test it somehow at the beamline to verify?

We should add a proper test.
Get Outlook for iOShttps://aka.ms/o0ukef
On Wed, Aug 3, 2016 at 2:44 PM -0400, "K Lauer" <notifications<EMAIL_ADDRESS>wrote:
Merged, but can (or should) we test it somehow at the beamline to verify?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/NSLS-II/bluesky/issues/533#issuecomment-237332216, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACLIrjDIfxtwiylJ5up1Z5ztm-w2Nrxuks5qcOGlgaJpZM4JbQX2.

Did it every correctly recover from a suspend, or was this happening every time?  Given that I was apparently wrong about this being rare, I am concerned that there is something wrong with my understanding and there is a deeper bug.

Me too. I will work on more tests on this tomorrow. I'm not all sure we have this logic right yet.

Closing due to no action in more than a year. Feel free to re-open. The planned suspenders re-write might address this if it's still a problem.


GH-102: Fix commit ID for actions/checkout v4.0.0

Fix GH-102

+1
Let's see what's happen by this. I hope that Dependabot opens a setup/checkout PR with tag (like https://github.com/apache/arrow-go/pull/93 ) not commit ID (like https://github.com/apache/arrow-go/pull/94 ).

Good: https://github.com/apache/arrow-go/pull/104


CookieManager asserts value isNotEmpty, but the cookie value can be empty in real world

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Not empty value cookie is not allowed.
Expected Behavior
Should allow empty cookie value.
Steps with code example to reproduce

Steps with code example to reproduce
// No code

Stacktrace/Logs

Stacktrace/Logs
<Replace this line by pasting your stacktrace or logs here>

Flutter version
v3.24.3
Operating System, Device-specific and/or Tool
Android API 30
Plugin version
v6.1.5
Additional information
Check the code here:
https://github.com/pichillilorenzo/flutter_inappwebview/blob/0aaf7a0bfc01d61a4d1453cefb57fb6783b6e676/flutter_inappwebview_android/lib/src/cookie_manager.dart#L79
Self grab

[ ] I'm ready to work on this issue!

Set-Cookie syntax in RFC 6265

set-cookie-header = "Set-Cookie:" SP set-cookie-string
set-cookie-string = cookie-pair *( ";" SP cookie-av )
cookie-pair       = cookie-name "=" cookie-value
cookie-name       = token
cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )

Which indicates that an empty cookie-value is legal.


Maps are broken

Just as a quick check, I took some of the old tests of the earlier closest PR to add map support (#149), and they all seem to fail, although the look superficially speaking correct to me. Am I missing something obvious?
cc @aleclarson @keenondrums

The tests should be wrapped with if (useProxies)
Once that was added, only two of these tests fail

ES5 is not supported? Then we should fix that first before releasing this
to the public. Shall we unpublish 3.1.0 for now?
On Thu, Apr 18, 2019 at 3:43 PM Alec Larson<EMAIL_ADDRESS>wrote:

The tests should be wrapped with if (useProxies)
Once that was added, only two of these tests fail
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/immerjs/immer/pull/353#issuecomment-484514839, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAN4NBFRFIRENEDG5URFBT3PRB3I3ANCNFSM4HG47CSA
.

@mweststrate I see ES5 support as an enhancement more than a requirement. Users should still avoid Map objects if they need to target ES5. I can add a warning in the readme.

No, that is a no-go area; Immer does support and maps can be polyfilled no
problem for IE 11. Proxies are a different ball game. The result of this
change is that devs can work happily for months on there immer + map
projects while devving. Having it blown into pieces the first time a IE
using customer arrives...
Maps should be supported in the ES5 implementation as well, or not be
released to avoid a lot of confusion and angry bug reports.
On Thu, Apr 18, 2019 at 3:51 PM Alec Larson<EMAIL_ADDRESS>wrote:

@mweststrate https://github.com/mweststrate I see ES5 support as an
enhancement more than a requirement. Users should still avoid Map objects
if they need to target ES5. I can add a warning in the readme.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/immerjs/immer/pull/353#issuecomment-484518379, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAN4NBADHXT7QP47ZYPS5DTPRB4F7ANCNFSM4HG47CSA
.

Also note that adding map support is a breaking change, as having maps in a
draft is going to behave entirely different now :). Unpublishing and
reverting the MR for now before someone trips over it.
On Thu, Apr 18, 2019 at 3:57 PM Michel Weststrate<EMAIL_ADDRESS>wrote:

No, that is a no-go area; Immer does support and maps can be polyfilled no
problem for IE 11. Proxies are a different ball game. The result of this
change is that devs can work happily for months on there immer + map
projects while devving. Having it blown into pieces the first time a IE
using customer arrives...
Maps should be supported in the ES5 implementation as well, or not be
released to avoid a lot of confusion and angry bug reports.
On Thu, Apr 18, 2019 at 3:51 PM Alec Larson<EMAIL_ADDRESS>wrote:

@mweststrate https://github.com/mweststrate I see ES5 support as an
enhancement more than a requirement. Users should still avoid Map
objects if they need to target ES5. I can add a warning in the readme.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/immerjs/immer/pull/353#issuecomment-484518379, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAN4NBADHXT7QP47ZYPS5DTPRB4F7ANCNFSM4HG47CSA
.

I made a whoopsie! :P

Also forgot to update the TypeScript defs :S

Could you revert and open a new PR? Let's take such a fundamental change a
bit slower next time :)
On Thu, Apr 18, 2019 at 4:03 PM Alec Larson<EMAIL_ADDRESS>wrote:

I made a whoopsie! :P
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/immerjs/immer/pull/353#issuecomment-484523747, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAN4NBDI2O3XPM2GY4SUZQLPRB5U7ANCNFSM4HG47CSA
.

https://github.com/immerjs/immer/pull/354


希望$router.toWebView支持本地路径

Your questions.
类似如下：
this.$router.toWebView({
url:'/assets/sign.html',
title:'签字',
navShow:false
});
Environment.

Mobile model: iphoneX
Mobile system: iOS 8
Dev platform: darwin/windows/linux
Node: 8.x.x
Npm: 5.x.x

What do you think may be caused by the analysis of the problem.

Reappearance of the problem (It's best to have a screenshot).

最新版本已支持，详情请看 https://bmfe.github.io/eros-docs/#/zh-cn/update_log_all?id=_20180704


move to drone 1.0.0

As title
Edit: Next steps include requesting a Drone Enterprise key from: https://my.drone.io/order/personal (ask Brad first if it's ok to use for Gitea, because it's not entirely personal but it's also not for business), and also setting up runners on ARM servers.

drone release 1.0?

@appleboy per suggestions I decided against using RC. So I will wait until 1.0.0 is released

Migration tool just updated with ability to migrate logs. Will run migration locally and comment on this PR if it is successful.

I ran the migration using the migration utility, and the DB went from 6.3GB->5.9GB. It appears as though everything has been migrated (from a few queries comparing the two DBs).
I think this is ready for review now.


Add a wiki: Gold Box Games Wiki

An anonymous user has submitted a new wiki via our submission form.
Link to origin wiki: https://goldbox.fandom.com
Link to destination (independent) wiki: https://wiki.goldbox.games

Looking through the indie wiki it appears to have only two pages (?) that have content not sourced from Wikipedia and is missing various game entries comparatively. All the game page links contain only a Wikipedia embed and Wikipedia indexes (eg: compare this entry to Wikipedia's).
However the Fandom wiki, for the game pages I checked, are pretty threadbare, mostly just containing links to stores (eg: that same game linked above), so perhaps the indie wiki authors thought that Wikipedia embeds are an improvement.
Though some Fandom pages have guides linked and some other pages are more fleshed out.


Mustache Error

When enabling this module, there's a Mustache error in the console about an unknown helper "fe", and no character sheets will load.

Fixed in 1.0.2.


Why is not possible to use this tool offline?

First of all, thanks for your work, this is an awesome tool, and in my case it works flawlessly.
It is much faster than OpenAI's Whisper, and I use it with CTranslate2.
I have a question. I have already downloaded the models, why must I be connected to the Internet while transcribing?
I see there is a request to Huggingface Hub or website... OpenAI's Whisper did not request to have an active connection to the Internet.
Here is my traceback:
File "/home/fz/.virtualenv/faster-whisper/lib/python3.11/site-packages/requests/sessions.py", line 701, in send
    r = adapter.send(request, **kwargs)

File "/home/fz/.virtualenv/faster-whisper/lib/python3.11/site-packages/requests/adapters.py", line 519, in send
    raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='huggingface.co', port=443): Max retries exceeded with url: /api/models/guillaumekln/faster-whisper-small/revision/main (Caused by NameResolutionError("<urllib3.connection.HTTPSConnection object at 0x7f8aea777410>: Failed to resolve 'huggingface.co' ([Errno -3] Temporary failure in name resolution)"))
Done!

Thanks in advance for your support.

What version of the library are you using? Since version 0.6 there should be no errors when the model is already downloaded and there is no internet connection.

This is the version of the CLI application I am using
(faster-whisper) [fz@fzpc faster-whisper]$ whisper-ctranslate2 --version
whisper-ctranslate2 0.2.4
And these are the libraries in my virtual environment
(faster-whisper) [fz@fzpc faster-whisper]$ cat <(ls lib/python3.11/site-packages)
av
av-10.0.0.dist-info
av.libs
certifi
certifi-2022.12.7.dist-info
cffi
cffi-1.15.1.dist-info
_cffi_backend.cpython-311-x86_64-linux-gnu.so
charset_normalizer
charset_normalizer-3.1.0.dist-info
ctranslate2
ctranslate2-3.13.0.dist-info
ctranslate2.libs
_distutils_hack
distutils-precedence.pth
faster_whisper
faster_whisper-0.5.1.dist-info
filelock
filelock-3.12.0.dist-info
fsspec
fsspec-2023.4.0.dist-info
huggingface_hub
huggingface_hub-0.14.1.dist-info
idna
idna-3.4.dist-info
numpy
numpy-1.24.3.dist-info
numpy.libs
nvidia
nvidia_cublas_cu11-<IP_ADDRESS>.dist-info
nvidia_cudnn_cu11-<IP_ADDRESS>.dist-info
packaging
packaging-23.1.dist-info
pip
pip-23.1.2.dist-info
pkg_resources
pycache
pycparser
pycparser-2.21.dist-info
PyYAML-6.0.dist-info
requests
requests-2.30.0.dist-info
setuptools
setuptools-67.4.0.dist-info
setuptools-67.4.0.virtualenv
sounddevice-0.4.6.dist-info
_sounddevice.py
sounddevice.py
src
tokenizers
tokenizers-0.13.3.dist-info
tokenizers.libs
tqdm
tqdm-4.65.0.dist-info
typing_extensions-4.5.0.dist-info
typing_extensions.py
urllib3
urllib3-2.0.2.dist-info
_virtualenv.pth
_virtualenv.py
wheel
wheel-0.38.4.dist-info
wheel-0.38.4.virtualenv
whisper_ctranslate2-0.2.4.dist-info
_yaml
yaml
faster-whisper seems is version 0.5... maybe this is the problem then... I will try to update then I will let you know.

It works, thank you.
I just activated my virtual environment and gave python -m pip install --upgrade faster-whisper; this solved the issue... I did not realize I was using an outdated version... this packages are not managed by my system's package manager, so I must remember to update them.
Thank you so much for your support!


feat(tui): add Portuguese (pt) locale

Here is what it looks like @ulissesf:

I think we're good to merge, thanks again for your time!

cc @0323pin for pt translation.


Android 6.0

When trying to place a call on Android 6.0, occurs an error with the following message : CouldNotCallPhoneNumber

use this
function permisioncall(){ 		cordova.plugins.diagnostic.requestRuntimePermission(function(status){ 		    switch(status){ 		        case cordova.plugins.diagnostic.permissionStatus.GRANTED: 		            console.log("Permission granted to use the camera"); 		            $scope.Call(); 		            break; 		        case cordova.plugins.diagnostic.permissionStatus.NOT_REQUESTED: 		            console.log("Permission to use the camera has not been requested yet"); 		            break; 		        case cordova.plugins.diagnostic.permissionStatus.DENIED: 		            console.log("Permission denied to use the camera - ask again?"); 		            break; 		        case cordova.plugins.diagnostic.permissionStatus.DENIED_ALWAYS: 		            console.log("Permission permanently denied to use the camera - guess we won't be using it then!"); 		            break; 		    } 		}, function(error){ 		    console.error("The following error occurred: "+error); 		}, cordova.plugins.diagnostic.runtimePermission.CALL_PHONE); 	}

Any update on this issue? I'm seeing the same problem since upgrading Android to version 6.


Cleanup of comments & unused args while working on Form Instance Loading

Removed javadoc method params that didn't have comments associated with them
Removed unused arguments from methods

Cross-request: https://github.com/dimagi/commcare-odk/pull/419
Only review after merging https://github.com/dimagi/javarosa/pull/122

@phillipm Hey, this looks fine to me. ready to pull.
One question: How broad of a net are you casting when you change method signatures? I don't believe it to be the case here, but a couple recent refactors broke, for instance, the CommCare and JavaRosa utility libraries used for the CLI, just wanted to be sure that we knew what needed to be included when library code signatures are changed.

Thanks for checking. When I remember I grep of all 3 repos and all their util builds (outside of the IDE). In this case I had forgotten to do that; luckily it looks like I caught all instances of 'populate'.
Should be good to go (other than needing to review/merge https://github.com/dimagi/javarosa/pull/122 first)


No sound

I am testing it at https://music.trom.tf/ but although it can seem to play everything, I get no sound output. Tried in Firefox and Chromium.
Context

Hardware: *VPS bought online
YunoHost version:  4.1.8 (stable).
I have access to my server: Through SSH | through the webadmin | direct access via keyboard / screen | ...
Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: *no
Using, or trying to install package version/branch: 3.1.1

Thanks for testing the app.
Mopidy tries to play the sounds on the audio hardware of your server.
This means that you need a real server with its own audio hardware to be able to use the app.
The user interface in the browser only serves as a kind of remote control.
I will try to describe this more clearly in the docs.

Ah ok makes sense. Yes please specify that in the readme. Many people, like me, are using a cloud vps for ynh. Cheers!


Exception caught trying to detect presets: could not open directory: /home/franka/Documents/librealsense2/presets/

I use ubuntu 20.04, and I have installed librealsense, but when running the command realsense-viewer, I got this error:
Exception caught trying to detect presets: could not open directory: /home/franka/Documents/librealsense2/presets/

And I can't get the RGB scenario under the cam.

Can someone please help to solve it? It's very urgent for me.

Hi @Shillin123  As the 'e' series of industrial RealSense-compatible cameras are not an Intel product but are instead manufactured and sold by FRAMOS, Intel RealSense technical support is unable to assist with this camera range unfortunately.  FRAMOS support should be contacted instead by visiting their website at the link below and clicking on the 'Let's Talk' button on the page.
https://www.framos.com/en/resources/support
However, I take into account the urgency of your need for a solution and can at least report that recently a D435e user experienced the same error on this support forum at https://github.com/IntelRealSense/librealsense/issues/10361 and found in their particular case that the error disappeared after opening and closing realsense-viewer a few times.
For further assistance if your problem continues, please contact FRAMOS support.

@MartyG-RealSense  Thanks for your quick reply. I will try it and also ask from FRAMOS.

Case closed due to FRAMOS being the support channel for 'e' cameras.


 Some are integration tests that take on the order of a few seconds, although even tests that take ~10ms still add up when many iterations are tested.
During development, I like to explore as much of the input space as possible, and I'm happy to set PROPTEST_CASES to a large number and let it run in the background. But once I'm satisfied with my code, my priorities shift to not slowing down CI too much. Since CI runs frequently, could I configure it to test just a few cases and still expect that over the course of many CI runs, the input space will still be explored?
Put another way, if I run a single test with the default value of PROPTEST_CASES=256, compared to 256 CI runs where PROPTEST_CASES=1, can I expect similar coverage?

I think this is a harder question to provide a complete answer for than it seems on the surface. If your test is over a function those interface is just scalar arguments, then default strategies will randomly sample within consistent bounds of those scalar arguments. In that case, coverage of 1 test (run * 256 cases) == (256 test runs * 1 case). With more complex testing strategies and implementations that may have nonlinear characteristics (such as where there's memoization is included), I'm not those runs will be exactly equal random variables.

For full disclosure I am a new maintainer here so I'll need to think about this more, there may be a simple answer for all cases and not just basic scalar cases. If someone else has that answer already feel free to provide it.

Thanks for the response! In my tests I don't have any memoization or state -- it's all scalars and collections.
If I'm reading the code correctly (and also based on my observations when running the tests) it seems like one thing to be aware of is the saved seeds from a regressions file. Since the runner runs those first, and they count towards the number of cases run, I believe that if I were to set PROPTEST_CASES <= num_regressions then the runner would never explore new inputs. This is something I can work around -- for example, by not committing the regressions file, and instead converting regressions into separate unit tests.

If I'm reading the code correctly (and also based on my observations when running the tests) it seems like one thing to be aware of is the saved seeds from a regressions file.

This seems like a bug given this.
https://github.com/proptest-rs/proptest/blob/1ad340e7c2276d0afc4c0ac13040a1861d198895/proptest/src/test_runner/config.rs#L182-L186
and I'm guessing you're referring to this in the code https://github.com/proptest-rs/proptest/blob/00f29af8e8138d4f58e592a1362bec1715733a41/proptest/src/test_runner/runner.rs#L656
I'll take a look at that separately, thanks for pointing that out!

@adeschamps fix merged and new release pushed. Thanks for taking the time to point out that issue.


Stable 3% (!!!) crashes realm::Allocator::translate_less_critical(realm::Allocator::RefTranslation*, unsigned long) const + 68

Goals
Realm crash free 99.N%
Expected Results
Realm crash free 99.N%
Actual Results
Realm crash free 97%
Steps for others to Reproduce
It is hard to reproduce it internally, because it's random crashes.
Code Sample

All Realm transactions(writes) from custom serial GCD queue within autoreleasepool.
New Realm instance each time.

let realmWriteQueue = DispatchQueue(label: "realmWriteQueue")
realmWriteQueue.async {
      autoreleasepool {
          do {
             let realm = try Realm(configuration: ...)
             try realm.write { //all writes ALWAYS here }
          } catch {}
      }
}

Stack trace:

We started seeing these crashes under heavy loads with very active database writes. Reproduced by 3 percent of users.
Realm framework version: 10.5.0
Xcode version: 12.4
iOS/OSX version: iOS 14.4
Dependency manager + version: CocoaPods 1.10.1

After upgrading to version 10.7.2, the problem still persists. Any help here?

After upgrading to version 10.7.2, the problem still persists. Any help here?

@igorvoytovich : Thanks for reporting. It appears to be a duplicate of: https://github.com/realm/realm-core/issues/4514, please direct further comments there.
If you do not believe it to be a duplicate, please reopen.

@finnschiermer Thank you for your response. Our crash is not related to SwiftUI in any way. I'll reopen issue.

@finnschiermer Thank you for your response. Our crash is not related to SwiftUI in any way. I'll reopen issue.

@igorvoytovich It's likely the same problem anyhow (I don't think swiftui is material to the other problem either), but I'm reopening for now.

@finnschiermer thanks. If you need any additional information please feel free to ask. We are really looking forward to solving this problem and will send the app update as soon as it is resolved.

FWIW - we rolled back to 4.3.2, which was the version we used before seeing these crashes and it's completely gone.
We were previously seeing 100-4000 instances of this crash daily depending on app usage.

@jpstern thanks for sharing this information. At the moment we have the same situation, more than 3000 crashes per day.
Could you please tell me if it is safe to rollback from version 10.7.2 to 4.3.2? That is, they are fully compatible and users should not have incompatibility problems?

We force deleted the realm file to prevent rollback issues.  The files aren't compatible so your users will get a crash if you try to just rollback

For the realm team - we were ultimately able to reliably reproduce the crash by running sustained very high volume concurrent writes.  Not necessarily a realistic real world scenario, but it was the only way to get the crash to happen.
It's possible low RAM is a factor for the the RLMRealm being autoreleased during a write transaction.  A noticeable percentage of the crashes showed low RAM on Crashlytics.

@jpstern thank you very much for the information.
@finnschiermer @tgoyne Since the current version is not production-ready, could you tell if we should wait for this problem to be fixed, or would it be more correct to roll back to the old version (4.3.2, for example, as mentioned above)? Thanks.

We run massive competing writes periodically as well and with much larger realm files, but haven't hit this issue, so there has to be more to it. Perhaps running low on memory is an important part of this.

@igorvoytovich We are actively investigating this issue, and I hope to be able to have an answer to your question (about wait or roll back) next week.

@finnschiermer thank you very much, I really appreciate it. Please feel free to contact me in case of any questions.

@finnschiermer @tgoyne Hello guys! We left the phone connected to Xcode overnight, and we were able to catch this crash. Below I attach a screenshot of the crash itself from Xcode:

I hope this information will be useful to you. Thanks.

@igorvoytovich FYI we have a tentative fix in development. You can follow it here: https://github.com/realm/realm-core/pull/4534

The fix is about how we handle an error condition when we're close to running out of memory. Likely implication: even if we fix this error, your app may fail shortly after, in a different way, due to the same underlying problem: using too much memory. You might be able to investigate this problem without waiting for our fix.

@finnschiermer
Thanks for your reply.
I'm pretty sure lack of memory is not the reason in our situation. As you can see in the crash screenshot above, our application uses memory efficiently and in total 100 MB was used.
Please correct me if I'm wrong.

Thx. That is obviously an indication that the fix may not address your error. We took the clue from @jpstern who commented about low memory higher in this issue. Perhaps we're dealing with two different issues then.

@finnschiermer
Then I think maybe we should rollback to some old version to check if there will be a problem there?
For example, version 5.5.0 (https://github.com/realm/realm-cocoa/blob/master/CHANGELOG.md#550-release-notes-2020-10-12).
We have no options why this problem may arise and what to do with it, for all metrics Realm works well and quickly.
I can describe in more detail how we use Realm, maybe this can help somehow:

All Realm transactions(writes) are from custom serial GCD queue within autoreleasepool. New Realm instance each time.

All Realm reads are from Main thread.

We actively use collection writes, like:
someResults.setValue(..., forKey: ...)

For example, we have N messages (ChatMessage) from user A, when we receive new user A model from backend, we save this user to Realm and update all the messages from this user (using above KV method) to have new actual user object.
By the way, does this function have limitations on array length? We couldn't find this in the documentation.

We do all this on the custom queue mentioned above, and after that we refresh the Realm on the main thread using the .refresh() function to get the actual data on the main thread.

We actively use Realm results notifications in many places.

It sounds like It sounds like https://github.com/realm/realm-core/pull/4534 is unlikely to help you (and if you were actually hitting the problem it fixes it wouldn't help much; gracefully reporting an error rather than crashing still usually doesn't leave the app in a working state). That's unsurprising as it was basically just a blind stab at finding a problem and fixing the first thing I found. I will keep digging for more potential things. Any more information you can provide about what's scenarios cause problems would help, but I don't have any specific suggestions.

For example, we have N messages from user A, when we receive new user A model from backend, we save this user to Realm and update all the messages from this user (using above KV method) to have new actual user object. By the way, does this function have limitations on array(results) length? We couldn't find this in the documentation.

The big advantage of this function over a manual loop is that it mostly avoids allocating any temporary objects. In theory it should work for arbitrarily large arrays.

@tgoyne
Thanks for your reply.
We had suspicions about this particular function, that is, we use it in several places, and often the update can affect up to several hundred objects (for example, messages in our case) at a time.
There are also suspicions that the forced refresh of Realm can affect, since we do it quite often. But, as far as I know, and as we understood from the documentation, this function is called on each RunLoop cycle anyway, that's why we use it so freely and haven't tried ThreadSafeReferences.
Perhaps we should redo the code from forced refreshes of Realm to use ThreadSafeReferences, in cases where we receive and save an object in another thread and immediately we need to work with it in the main thread? How do you think?

Explicitly calling refresh() will block the main thread until the notification worker is done processing a write, while otherwise we delay notifying the main thread until that's done so that it can continue to process user interaction. It otherwise behaves identically to automatic refreshes.
Resolving a ThreadSafeReference which was created at a later version than the local Realm is at just calls refresh() internally. It's theoretically faster than looking up the object by PK again but it's a negligible difference. TSR is mostly only interesting for object types without primary keys.

You've only seen this on iOS devices and not in the simulator, right? The xover mapping logic is full of atomics that look right, but a bug in them which is hidden on x86 by the stricter memory model would make a lot of sense.

@tgoyne
Yes, we see this crash on real devices. On our side, we were able to reproduce it on iPhone SE 2020, iOS 14.4

@tgoyne
Thank you very much for your detailed explanations. I really appreciate it.

One thing I notice is that one of the stack traces is showing a write transaction being cancelled due to the RLMRealm being deallocated while in a write transaction. Is that a thing you expect to have happening sometimes?
Does the device which reproduced it have free disk space? I doubt that's the problem but just to eliminate it as a possibility...

@tgoyne
We were able to reproduce this on a test device with over 50GB of free disk space, which we use exclusively for testing our application.
As for RAM memory, according to Xcode, our application consumes no more than 100-110 MB with active use, which is no more than 3-4% according to Xcode analytics.

@tgoyne hello, we caught another crash with a request to report it in the logs. Maybe somehow connected.
Here are screenshots:

@tgoyne @finnschiermer
Hello,
Some time ago we sent a version of the application with RealmSwift v5.5.2 to a limited audience for a test. And I can confirm that this crash is not reproduced on this version of the Realm SDK.
Could you please tell us whether we should wait for some fix or it would be better to transfer all users to the old version of the SDK?
Thanks.

We are seeing the same problem. Could you please tell if there will be any fix?
@tgoyne @finnschiermer

@tgoyne @finnschiermer
Hello,
I would like to clarify if there is any progress on this issue?
More than 2 months have passed, and we would like to understand what to do with this next.
Please let me know if you need any additional information, I will gladly provide you with it.
Thanks.

Hi @igorvoytovich are you able to reproduce this with cocoa version 10.7.6? I just noticed that the stack trace of a bug we fixed is very similar to what you reported above. This is still a guess, but the conditions of the fixed bug seem to match a couple of the clues in this issue; a sync app advancing or rolling back a transaction which first created a tombstone table (meaning some data shared between sync users was deleted by someone for the first time).

@ironage
Hello,
Thanks for your message.
Unfortunately I can still reproduce this on 10.7.6.
If I understood you correctly, you are talking about data synchronization between several users, if so, then this is definitely not our case, since we use Realm exclusively locally.

@igorvoytovich thanks for testing it out so quickly! I agree, if your app is not using Realm sync then the fix I linked is unrelated.

Hello,
There is another example of the crash step by step:

We have the same problem. Are there any updates?
@tgoyne @finnschiermer

@finnschiermer ,
thanks for getting back to me.
We are seeing these crashes on real iPhones. To be more specific: iPhone SE 2, iPhone 11 Pro Max. All on iOS 14.5-14.6.
For development and deployment, we use only Macs with an M1 chip, integration via CocoaPods.
We've tried a bunch of things already, and we can't even imagine where the mistake might be on our side, from our side the code is as simple and predictable as possible.
If you have any questions, please do not hesitate to ask anytime.
By the way, we already use 10.8.0 version of SDK, and the problem still persist.

@tgoyne @finnschiermer
Hello,
Could you please tell if there is a difference between:
try realm.write { //Realm work here... }
and
realm.beginWrite()
//Realm work here...
try realm.commitWrite()

By the SDK code, I see that the first option calls the second one, with additional error handling, but I am confused by line 257:

Considering the fact and as you can see from the screenshots above that we have a lot of problems with the cancelWrite () / cancelWriteTransaction() function, I think this may be somehow related. We will try to replace all work with Realm with the use of the second option for creating a transaction.
I also want to note that there are places in the documentation where the second method is used, but without explanation why and when it is better to use it. Please take a look:

Thanks.

We tried beginWrite() and commitWrite() and got the same problem.
We also changed the object schemes a little in order to find out what the problem is, namely, removed the indexed properties. And we got the same crash, but with a new stack trace:

@tgoyne @finnschiermer I hope this helps somehow

By the way, people had the same problem, but the issue was closed without any changes:
https://github.com/realm/realm-cocoa/issues/6690

@igorvoytovich what does your observation code look like?

@jsflax
hi, here it is:

I added such a logging function and call it every time after a transaction to Realm. As you can see, the file size grows significantly even when the number of objects does not change. This continues until the application crashes.
What could be the problem?

Reproducable after some time using the app / Realm, here's another example:

And so it will continue indefinitely, until it takes away all the memory. Realm works as it should for a while, then after something it breaks down and a strong memory growth begins, regardless of the activity of transactions.

@tgoyne @finnschiermer @jsflax
I can confirm that these problems are not present on RealmSwift 4.3.2.
We checked on the same project, everything that changed is replaced freeze() with detached() (https://github.com/realm/realm-cocoa/issues/5433#issuecomment-415066361) , because freeze was added after 4.3.2
On this SDK version, Realm works perfectly, without going beyond the size of 1 MB on our data volumes.

I beg you to tell us what to do in this situation, should we wait for any changes? Or should we consider replacing Realm or downgrading to a lower version (4.3.2)?
I hope for your understanding, because due to these problems we are suffering large financial losses and we need to resolve this as soon as possible.

Can you show us where/how you're using freeze? Freezing objects uses version pinning which can greatly increase the size of a Realm file.

We save users objects and collect the array on another thread (realmWriteThread) and send it to the main thread in this way.

(users - [User] array of manager objects, managed by Realm on realmWriteQueue)
The fact is that Realm retains its size between application restarts. I thought that freezed is just an Unmanager copy of realm object, how can it affect Realm size?
@jsflax

@jsflax
Seems like you are right. After replacing freeze() with detached() (https://github.com/realm/realm-cocoa/issues/5433#issuecomment-415066361) I can not reproduce the problem for now. So whats the point of using freeze() then?
I will monitor for a few hours and will get back here with results.
By the way, is it normal that on 10.8.1 objects with same schema is 30-40% larger than on 4.3.2?

Freeze is used for when you want an immutable value that is easily transferable between threads. It's not meant to be used for longstanding operations, especially off of the main thread.
We see most users using freeze as a means of diffing values (a necessity since Realm types are always 'live'). If you do not need that kind of behaviour, I would consider alternatives to what you are doing. Holding onto frozen values should be done with caution.

After stopping using freeze(), the problem went away. Everything is working perfectly now.
I hope that our experience will help other people who have faced similar problems.
@finnschiermer @tgoyne @jsflax @ironage
I am very grateful to you for your time and help. I really appreciate that.
Many thanks! Best wishes to you!

@igorvoytovich I'm happy it has solved your problem. From my perspective there is still a problem to fix: whether you use freeze as intended or not, we shouldn't have a crash in the allocator.


fix(gateway): always masquerade for docker-deployed gateways

Without masquerading, packets sent by the gateway through the TUN interface use the wrong source address (the TUN device's address) instead of the gateway's actual network interface.
We set this env variable in all our uses of the gateway, thus we might as well remove it and always perform unconditionally.

I can imagine a few cases where you want to run the gateway only for local interfaces and no forwarding, aren't we losing that kind of configuration doing this?

I can imagine a few cases where you want to run the gateway only for local interfaces and no forwarding, aren't we losing that kind of configuration doing this?

In docker? If people are extending our Dockerfile, they need to override the entry point anyway and thus can configure whatever they need. As soon as the gateway is running as a sidecar, we need masquerading.

I can imagine a few cases where you want to run the gateway only for local interfaces and no forwarding, aren't we losing that kind of configuration doing this?

In docker? If people are extending our Dockerfile, they need to override the entry point anyway and thus can configure whatever they need. As soon as the gateway is running as a sidecar, we need masquerading. Or am I missing something?

I'm just unsure that masquerade is needed for 2 docker containers working in the same host, depends on how docker configures the routing table/bridge interfaces, right?

I can imagine a few cases where you want to run the gateway only for local interfaces and no forwarding, aren't we losing that kind of configuration doing this?

In docker? If people are extending our Dockerfile, they need to override the entry point anyway and thus can configure whatever they need. As soon as the gateway is running as a sidecar, we need masquerading. Or am I missing something?

I'm just unsure that masquerade is needed for 2 docker containers working in the same host, depends on how docker configures the routing table/bridge interfaces, right?

I am happy to be proven wrong but I was unable to make a gateway-sidecar within a docker-compose file work. I think regardless of how the networks are configured, as soon as you have two hosts, the traffic leaving the gateway host must use whatever the source IP of that egress interface is and not the source IP of the TUN interface.
For example, on a gateway in a compose file, I see the following network adapters:
/bin # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: tun-firezone: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN qlen 500
    link/[65534]
    inet <IP_ADDRESS>/32 brd <IP_ADDRESS> scope global tun-firezone
       valid_lft forever preferred_lft forever
    inet6 fd00:2021:1111::12:a636/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::f31b:f64a:4c93:735d/64 scope link flags 800
       valid_lft forever preferred_lft forever
27: eth0@if28: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:1b:00:02 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe1b:2/64 scope link
       valid_lft forever preferred_lft forever

Any resource that the gateway should reach must go via the eth0 interface. Without masquerading, the traffic sent through that interface will use <IP_ADDRESS> or fd00:2021:1111::12:a636 as the source IP which is wrong. It needs to be re-written to <IP_ADDRESS> so it can be routed back correctly.

I can imagine a few cases where you want to run the gateway only for local interfaces and no forwarding, aren't we losing that kind of configuration doing this?

In docker? If people are extending our Dockerfile, they need to override the entry point anyway and thus can configure whatever they need. As soon as the gateway is running as a sidecar, we need masquerading. Or am I missing something?

I'm just unsure that masquerade is needed for 2 docker containers working in the same host, depends on how docker configures the routing table/bridge interfaces, right?

I am happy to be proven wrong but I was unable to make a gateway-sidecar within a docker-compose file work without masquerading. I think regardless of how the networks are configured, as soon as you have two hosts, the traffic leaving the gateway host must use whatever the source IP of that egress interface is and not the source IP of the TUN interface.
For example, on a gateway in a compose file, I see the following network adapters:
/bin # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet <IP_ADDRESS>/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: tun-firezone: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN qlen 500
    link/[65534]
    inet <IP_ADDRESS>/32 brd <IP_ADDRESS> scope global tun-firezone
       valid_lft forever preferred_lft forever
    inet6 fd00:2021:1111::12:a636/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::f31b:f64a:4c93:735d/64 scope link flags 800
       valid_lft forever preferred_lft forever
27: eth0@if28: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:1b:00:02 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe1b:2/64 scope link
       valid_lft forever preferred_lft forever

Any resource that the gateway should reach must go via the eth0 interface. Without masquerading, the traffic sent through that interface will use <IP_ADDRESS> or fd00:2021:1111::12:a636 as the source IP which is wrong. It needs to be re-written to <IP_ADDRESS> so it can be routed back correctly.

Ah, you're right that it wouldn't work. But because I think it'll actually use the source IP of the client's interface since we just write that to our interface, it doesn't do any mangling of the packet without masquerading.
If the packet were to use the source <IP_ADDRESS> the routing table would know that packets with dst(the responses) <IP_ADDRESS> would have to be routed to tun-firezone.
But since we set the tun-firezone to /32 instead of /10 there's no way that docker adds a route back to tun-firezone for the client's IP.
If we changed that to use /10 I think the OS would have a route back but I'm not sure how that would interact with docker.

I think we should leave this configurable. IIRC there are some use cases that strictly don't work with masquerading enabled.
See example thread #666

It is still configurable. Users just need to make a custom Docker init script.
In the systemd unit file for the gateway, this also isn't configurable: https://github.com/firezone/firezone/blob/64a9efd3b83ab8c3bdb2a9a8638124a6fa60d2fe/scripts/gateway-systemd-install.sh#L101-L109


Crash/hang on file explorer dialogue open (e.g. open file/folder or save file)

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.66.0
OS Version: ubuntu 18.04

Steps to Reproduce:

start VS Code with --disable-extensions flag enabled
anything that brings up the file explorer e.g. opening a file/folder, saving a new file or save existing file as will cause vscode to hang.
I've noticed that the text indicator continues to flash in the editor, but everything is uninteractive and eventually the only option is to force quit.

Sounds a bit like #146425

/duplicate https://github.com/microsoft/vscode/issues/146584


add codeready configuration

add a .factory.json file so that this app can be easily imported into a CodeReady (Che) workspace
add network security configuration to support self-signed certs for android.

To verify:

Have CodeReady running somewhere.
Change the url of the CodeReady console to https:///f?url=https://github.com/wei-lee/ionic-showcase/tree/codeready-update
Wait for the workspace to be ready. Once it is ready, you should see the project is imported and you can run the build command and serve command from the workspace