Stop using _id and gensym?

IMHO using gemsym dynamically is not really the best practice as it leaks memory.  It also is slow compared to (say) UUID
julia> @btime uuid4();
  11.958 ns (0 allocations: 0 bytes)

julia> @btime gensym();
  1.082 μs (0 allocations: 0 bytes)

These are not very critical problems but it's nice if we can avoid it.  I think we can easily avoid it by introducing a new key value (say) progressid such that
@logmsg ProgressLevel name progress=0.1 progressid=id

is used instead of
@logmsg ProgressLevel name progress=0.1 _id=id

Then id can be of any type.  The easiest thing to use may be uuid4().

Agreed.
We should still specify that the Logger falls back to _id if progressid isn't used, so that
for i in 0:0.1:1
   sleep(0.5)
   @logmsg -1 "foo" progress=i
end

continues to work.

Thinking about this and #8, I started wondering if it makes sense to use a single key like this
@logmsg ProgressLevel name progress=Progress(0.1, id, parentid)

where
Base.@kwdef struct Progress
    progress::Float64
    id::UUID
    parentid::UUID = UUID(0)  # not nested by default
end

This has a benefit that:

The top level keys are not cluttered.
It is easy to construct progress events programmatically.
Adding new API or extending the old one is easier (e.g., iterators with unknown length https://github.com/JunoLab/Juno.jl/issues/222)
Changes in API is easy to propagate.

Backends (log handlers) using _id-based old specification are likely to check if progress is a Real or "done".  They would just ignore new Progress type in this case.
For backward-compatible changes, we can just append optional arguments to Progress constructor.
For backward-incompatible changes (after transitioned to Progress), we can introduce a new struct (or bump ProgressLogging.jl's major version number if we absolutely have to).

Maybe it makes sent to put above struct in ProgressBase.jl, since this is what both frontend and backend needs while the backend does not need @progress macro etc.  It can be done anytime later, though.

I like it.
Would still be nice to have a way to use the @logmsg API without worrying about ids at all, so we maybe should add a macro-constructor so you can do
for i in 0:0.1:1
   sleep(0.5)
   @logmsg -1 "foo" progress=@Progress(0.1)
end

IMHO we should also keep all other kwargs supplied to Progress somewhere, so log handlers can have specialized fields (Juno for example supports right_text and message).

Instead of @Progress, maybe we can use @logprogress?  ATM we have
@withprogress begin
    for i = 1:10
        sleep(0.5)
        @logprogress "iterating" progress=i/10
    end
end

I think @logprogress "iterating" progress=0.1 can be easily lowered to @logmsg ProgressLevel "iterating" progress=Progress(0.1, id).
Thinking this a bit more, I wonder if we should only expose a smaller @logprogress API like this
@logprogress progress [message=value] [right_text=value]

which would be used as
@withprogress name="iterating" begin
    for i = 1:10
        sleep(0.5)
        if i == 10
            @logprogress i/10 message="this is the last one"
        else
            @logprogress i/10
        end
    end
end

(where name is passed to @logmsg inside the for loop body via a gensym'ed local variable)
This way, we can be more flexible about the upgrade path to Progress struct.

IMHO we should also keep all other kwargs supplied to Progress somewhere, so log handlers can have specialized fields (Juno for example supports right_text and message).

Since @logmsg already allows arbitrary keyword arguments, I wonder if it is enough to use them for the extension to the core progress API.

Thanks for the demo. I see. It makes sense to support changing the name. So, how about this syntax?
@logprogress [name] progress [key1=val1 [key2=val2 ...]]

i.e., make name optional and progress positional.

I'd also kinda like it if the @logmsg API would still be supported

I think I understand the benefit but I'm a bit ambivalent about this direction.  But we are going to have a phase supporting both specs anyway if we are to switch to Progress type-based API.  I think it would then be reasonable to provide utility functions for logger monitor packages to "merge" those two APIs.  If this compatibility layer is simple enough to maintain (it probably is), I think I'd be happy with this choice.

I agree that dynamic gensym() should be avoided. I do think a macro-based version of this would make sense with a statically generated id.
Hmm, concurrent tasks would get the same id when running a given loop which is annoying. That could be dealt with by adding a task id when grouping into progress bars. Or generating a UUID.
The _id doesn't need to be a symbol, by the way. It could be a UUID in principle.

Hmm, concurrent tasks would get the same id when running a given loop which is annoying.

I had the same thought. But actually you only need a recursive function to break macro-based _id:
foreachprod(f) = f(())
function foreachprod(f, it, itrs...)
    for (i, x) in enumerate(it)
        @info "foreachprod" progress = i / length(it)
        foreachprod(itrs...) do y
            f((x, y...))
        end
    end
end

This function requires nested bars but produces only one _id.
Another example from https://tkf.github.io/Transducers.jl/dev/manual/#Transducers.withprogress:
xf = MapCat() do x
    withprogress(1:x; interval=1e-3)  # nested progress
end |> Map() do x
    sleep(0.5)
    x
end

foldl(+, xf, withprogress(1:10; interval=1e-3))

The _id doesn't need to be a symbol, by the way.

Logging.handle_message says

id is an arbitrary unique Symbol to be used as a key to identify the log statement when filtering.

So I've been assuming that it has to be a symbol.  Maybe we should fix the doc, if this is not indented?

Quoting @c42f's comment

Progress is currently detected via the _id and progress key. But perhaps progress "should" be determined by the type of the message?
@info Progress("msg", fraction)

--- https://github.com/c42f/TerminalLoggers.jl/pull/4#discussion_r345536346


Add STAC extensions for lineage, lifecycle and manager and custodian

User Story

So that I can ensure all the LINZ required metadata is attached to my data, as a Data Maintainer, I want my metadata validated against a 'linz:providers' prioperty, a 'quality:lineage' property and a 'linz:lifecycle' property.

Acceptance Criteria

[x] create a mandatory linz:providers property that is identical to the 'providers' in stac-spec core definition but with the roles being an enumeration of manager and custodian. STAC people suggested doing this another way? Do we know how to do this?
[x] Add 'quality:lineage' property (Text) to quality extenstion and make mandatory
[x] Add  'linz:lifecycle' property (Enumeration "under development", "preview", "on going", "completed", "deprecated") - add and make mandatory

Additional context

See new metadata analysis. We can probably combine our rules with the STAC JSON schema easily.
Tasks

[ ] ...
[ ] ...

Definition of Ready

[ ] This story is ready to work on

[ ] Independent (story is independent of all other tasks)
[ ] Negotiable (team can decide how to design and implement)
[ ] Valuable (from a user perspective)
[ ] Estimate value applied (agreed by team)
[ ] Small (so as to fit within an iteration)
[ ] Testable (in principle, even if there isn't a test for it yet)
[ ] Environments are ready to meet definition of done
[ ] Resources required to implement will be ready
[ ] Everyone understands and agrees with the tasks to complete the story
[ ] Release value (e.g. Iteration 3) applied
[ ] Sprint value (e.g. Aug 1 - Aug 15) applied

Definition of Done

[ ] This story is done:

[ ] Acceptance criteria completed
[ ] Automated tests are passing
[ ] Code is peer reviewed and pushed to master
[ ] Deployed successfully to test environment
[ ] Checked against CODING guidelines
[ ] Relevant new tasks are added to backlog and communicated to the team
[ ] Important decisions recorded in the issue ticket
[ ] Readme/Changelog/Diagrams are updated
[ ] Product Owner has approved acceptance criteria as complete
[ ] Meets non-functional requirements:

[ ] Scalability (data): Can scale to 300TB of data and 100,000,000 files and ability to
increase 10% every year
[ ] Scability (users): Can scale to 100 concurrent users
[ ] Cost: Data can be stored at < 0.5 NZD per GB per year
[ ] Performance: A large dataset (500 GB and 50,000 files - e.g. Akl aerial imagery) can be
validated, imported and stored within 24 hours
[ ] Accessibility: Can be used from LINZ networks and the public internet
[ ] Availability: System available 24 hours a day and 7 days a week, this does not include
maintenance windows < 4 hours and does not include operational support
[ ] Recoverability: RPO of fully imported datasets < 4 hours, RTO of a single 3 TB dataset <
12 hours

@MitchellPaff as discussed, can you see if you can make it mandatory to always have two provider objects for all metadata, one of each role type, i.e. one managerand one custodian.

Looks good. Thanks @MitchellPaff


Check failed: err == cudaSuccess (7 vs. 0) Name: col2im_gpu_kernel ErrStr:too many resources requested for launch

the terminal  suggest "you can try set environment variable MXNET_ENGINE_TYPE to NaiveEngine and run with debugger (i.e. gdb)." What should i do?

try using cudnn plz

i make the "USE_CUDNN = 1" in /mxnet/make/config.mk, and recompile the mxnet ,but now still show error:
Check failed: err == cudaSuccess (7 vs. 0) Name: MapRedKeepLowestKernel ErrStr:too many resources requested for launch
and the terminal suggests:
An fatal error occurred in asynchronous engine operation. If you do not know what caused this error, you can try set environment variable MXNET_ENGINE_TYPE to NaiveEngine and run with debugger (i.e. gdb). This will force all operations to be synchronous and backtrace will give you the series of calls that lead to this error. Remember to set MXNET_ENGINE_TYPE back to empty after debugging.
how to solve this problem？ thank you!

Again, could you provide the environment you are using? GPU/CUDA version etc.

Ubuntu 14.04.2
GPU:TITAN X;
CUDA8.0;
python2.7;
numpy1.8.2

Can this problem be solved? Hope help!

You'd better provide more details about your training configures.
For example, size of images you used, etc.

@lisabug @winstywang
This error happened when starting training the RCNN part. The (first) RPN part trained successfully.
And I trained this using cityscape dataset.
In addition, GPU TITAN X (Pascal)
Should i change the "gencode arch=compute_$(arch),code=sm_$(arch)" in /mxnet/Makefile? And how to  change?
thank you!

@994374821 try updating the cudnn to latest one.

@994374821 I get the same problem with you. have you solve it？　ｈｏｗ？

Hey folks,
We find a possible solution to this issue. At least it seems work in our testing environment. We will further confirm this, and return to you soon.

Hi, we solve the too many resources requested for launch problem by adding MSHADOW_CFLAGS += -DMSHADOW_OLD_CUDA=1 in mxnet/mshadow/make/mshadow.mk.
This macro limits the threads of kernel launch, refer https://github.com/dmlc/mshadow/blob/3a400b4662bf42e885592fd07bd51335532a8bc8/mshadow/cuda/tensor_gpu-inl.cuh#L25 for more details.
So, please try add this macro and re-compile mxnet, then test our codes, thanks.

@huangzehao Hi, I need your help!   I add the macro , and re-compile mxnet, then run "bash scripts/train_alternate.py" . However, there have the following errors :
init_bbox_pred(k, arg_params[k])
init rcnn_fc_bbox_bias
init mask_conv_1_weight
init mask_conv_1_bias
init mask_conv_2_weight
init mask_conv_2_bias
init mask_conv_3_weight
init mask_conv_3_bias
init mask_conv_4_weight
init mask_conv_4_bias
init mask_deconv_1_weight
init mask_deconv_2_weight
init mask_deconv_2_bias
lr 0.004 lr_epoch_diff [20] lr_iters [59300]
/home/surge/hll/mx-maskrcnn/rcnn/core/metric.py:69: DeprecationWarning: Numeric-style type codes are deprecated and will result in an error in the future.
label.append(labels[self.label.index('rcnn_label_stride%s' % s)].asnumpy().reshape((-1,)).astype('Int32'))
/home/surge/hll/mx-maskrcnn/rcnn/core/metric.py:177: DeprecationWarning: Numeric-style type codes are deprecated and will result in an error in the future.
label.append(labels[self.label.index('rcnn_label_stride%s' % s)].asnumpy().reshape((-1,)).astype('Int32'))
/home/surge/hll/mx-maskrcnn/rcnn/core/metric.py:222: DeprecationWarning: Numeric-style type codes are deprecated and will result in an error in the future.
label.append(labels[self.label.index('rcnn_label_stride%s' % s)].asnumpy().reshape((-1,)).astype('Int32'))
/home/surge/hll/mx-maskrcnn/rcnn/core/metric.py:122: DeprecationWarning: Numeric-style type codes are deprecated and will result in an error in the future.
label.append(labels[self.label.index('rcnn_label_stride%s' % s)].asnumpy().reshape((-1,)).astype('Int32'))
[15:08:38] /home/surge/hll/mx-maskrcnn/incubator-mxnet/dmlc-core/include/dmlc/logging.h:308: [15:08:38] /home/surge/hll/mx-maskrcnn/incubator-mxnet/mshadow/mshadow/././././cuda/tensor_gpu-inl.cuh:118: Check failed: err == cudaSuccess (7 vs. 0) Name: MapPlanLargeKernel ErrStr:too many resources requested for launch
Stack trace returned 10 entries:
[bt] (0) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN4dmlc15LogMessageFatalD1Ev+0x3c) [0x7f881b214acc]
[bt] (1) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN7mshadow4cuda7MapPlanINS_2sv6savetoENS_6TensorINS_3gpuELi4EfEENS_4expr9ScalarExpIfEEfEEvNS7_4PlanIT0_T2_EERKNSA_IT1_SC_EENS_5ShapeILi2EEEP11CUstream_st+0x351) [0x7f881d6386d1]
[bt] (2) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN7mshadow6MapExpINS_2sv6savetoENS_6TensorINS_3gpuELi4EfEELi4EfNS_4expr9ScalarExpIfEELi1EEEvPNS_7TRValueIT0_S4_XT1_ET2_EERKNS6_3ExpIT3_SB_XT4_EEE+0x79) [0x7f881d6388a9]
[bt] (3) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(ZN5mxnet2op6CropOpIN7mshadow3gpuEE8BackwardERKNS_9OpContextERKSt6vectorINS_5TBlobESaIS9_EESD_SD_RKS8_INS_9OpReqTypeESaISE_EESD_SD+0x25f) [0x7f881e5c104f]
[bt] (4) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(ZN5mxnet2op13OperatorState8BackwardERKNS_9OpContextERKSt6vectorINS_5TBlobESaIS6_EERKS5_INS_9OpReqTypeESaISB_EESA+0x2c7) [0x7f881d27c4d7]
[bt] (5) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet4exec23StatefulComputeExecutor3RunENS_10RunContextEb+0xbb) [0x7f881d09259b]
[bt] (6) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(+0x26c58e7) [0x7f881d0978e7]
[bt] (7) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet6engine14ThreadedEngine15ExecuteOprBlockENS_10RunContextEPNS0_8OprBlockE+0x9d) [0x7f881d079cbd]
[bt] (8) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet6engine23ThreadedEnginePerDevice9GPUWorkerILN4dmlc19ConcurrentQueueTypeE0EEEvNS_7ContextEbPNS1_17ThreadWorkerBlockIXT_EEESt10shared_ptrINS0_10ThreadPool11SimpleEventEE+0x103) [0x7f881d07de13]
[bt] (9) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(ZNSt17_Function_handlerIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEZZNS2_23ThreadedEnginePerDevice13PushToExecuteEPNS2_8OprBlockEbENKUlvE1_clEvEUlS5_E_E9_M_invokeERKSt9_Any_dataS5+0x56) [0x7f881d07e016]
[15:08:38] /home/surge/hll/mx-maskrcnn/incubator-mxnet/dmlc-core/include/dmlc/logging.h:308: [15:08:38] src/engine/./threaded_engine.h:370: [15:08:38] /home/surge/hll/mx-maskrcnn/incubator-mxnet/mshadow/mshadow/././././cuda/tensor_gpu-inl.cuh:118: Check failed: err == cudaSuccess (7 vs. 0) Name: MapPlanLargeKernel ErrStr:too many resources requested for launch
Stack trace returned 10 entries:
[bt] (0) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN4dmlc15LogMessageFatalD1Ev+0x3c) [0x7f881b214acc]
[bt] (1) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN7mshadow4cuda7MapPlanINS_2sv6savetoENS_6TensorINS_3gpuELi4EfEENS_4expr9ScalarExpIfEEfEEvNS7_4PlanIT0_T2_EERKNSA_IT1_SC_EENS_5ShapeILi2EEEP11CUstream_st+0x351) [0x7f881d6386d1]
[bt] (2) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN7mshadow6MapExpINS_2sv6savetoENS_6TensorINS_3gpuELi4EfEELi4EfNS_4expr9ScalarExpIfEELi1EEEvPNS_7TRValueIT0_S4_XT1_ET2_EERKNS6_3ExpIT3_SB_XT4_EEE+0x79) [0x7f881d6388a9]
[bt] (3) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(ZN5mxnet2op6CropOpIN7mshadow3gpuEE8BackwardERKNS_9OpContextERKSt6vectorINS_5TBlobESaIS9_EESD_SD_RKS8_INS_9OpReqTypeESaISE_EESD_SD+0x25f) [0x7f881e5c104f]
[bt] (4) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(ZN5mxnet2op13OperatorState8BackwardERKNS_9OpContextERKSt6vectorINS_5TBlobESaIS6_EERKS5_INS_9OpReqTypeESaISB_EESA+0x2c7) [0x7f881d27c4d7]
[bt] (5) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet4exec23StatefulComputeExecutor3RunENS_10RunContextEb+0xbb) [0x7f881d09259b]
[bt] (6) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(+0x26c58e7) [0x7f881d0978e7]
[bt] (7) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet6engine14ThreadedEngine15ExecuteOprBlockENS_10RunContextEPNS0_8OprBlockE+0x9d) [0x7f881d079cbd]
[bt] (8) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet6engine23ThreadedEnginePerDevice9GPUWorkerILN4dmlc19ConcurrentQueueTypeE0EEEvNS_7ContextEbPNS1_17ThreadWorkerBlockIXT_EEESt10shared_ptrINS0_10ThreadPool11SimpleEventEE+0x103) [0x7f881d07de13]
[bt] (9) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(ZNSt17_Function_handlerIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEZZNS2_23ThreadedEnginePerDevice13PushToExecuteEPNS2_8OprBlockEbENKUlvE1_clEvEUlS5_E_E9_M_invokeERKSt9_Any_dataS5+0x56) [0x7f881d07e016]
A fatal error occurred in asynchronous engine operation. If you do not know what caused this error, you can try set environment variable MXNET_ENGINE_TYPE to NaiveEngine and run with debugger (i.e. gdb). This will force all operations to be synchronous and backtrace will give you the series of calls that lead to this error. Remember to set MXNET_ENGINE_TYPE back to empty after debugging.
Stack trace returned 8 entries:
[bt] (0) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN4dmlc15LogMessageFatalD1Ev+0x3c) [0x7f881b214acc]
[bt] (1) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet6engine14ThreadedEngine15ExecuteOprBlockENS_10RunContextEPNS0_8OprBlockE+0x3a0) [0x7f881d079fc0]
[bt] (2) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet6engine23ThreadedEnginePerDevice9GPUWorkerILN4dmlc19ConcurrentQueueTypeE0EEEvNS_7ContextEbPNS1_17ThreadWorkerBlockIXT_EEESt10shared_ptrINS0_10ThreadPool11SimpleEventEE+0x103) [0x7f881d07de13]
[bt] (3) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(ZNSt17_Function_handlerIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEZZNS2_23ThreadedEnginePerDevice13PushToExecuteEPNS2_8OprBlockEbENKUlvE1_clEvEUlS5_E_E9_M_invokeERKSt9_Any_dataS5+0x56) [0x7f881d07e016]
[bt] (4) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZNSt6thread5_ImplISt12_Bind_simpleIFSt8functionIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEES8_EEE6_M_runEv+0x3b) [0x7f881d07b25b]
[bt] (5) /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb1a60) [0x7f8835789a60]
[bt] (6) /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) [0x7f883b431182]
[bt] (7) /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f883b15e47d]
terminate called after throwing an instance of 'dmlc::Error'
what():  [15:08:38] src/engine/./threaded_engine.h:370: [15:08:38] /home/surge/hll/mx-maskrcnn/incubator-mxnet/mshadow/mshadow/././././cuda/tensor_gpu-inl.cuh:118: Check failed: err == cudaSuccess (7 vs. 0) Name: MapPlanLargeKernel ErrStr:too many resources requested for launch
Stack trace returned 10 entries:
[bt] (0) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN4dmlc15LogMessageFatalD1Ev+0x3c) [0x7f881b214acc]
[bt] (1) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN7mshadow4cuda7MapPlanINS_2sv6savetoENS_6TensorINS_3gpuELi4EfEENS_4expr9ScalarExpIfEEfEEvNS7_4PlanIT0_T2_EERKNSA_IT1_SC_EENS_5ShapeILi2EEEP11CUstream_st+0x351) [0x7f881d6386d1]
[bt] (2) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN7mshadow6MapExpINS_2sv6savetoENS_6TensorINS_3gpuELi4EfEELi4EfNS_4expr9ScalarExpIfEELi1EEEvPNS_7TRValueIT0_S4_XT1_ET2_EERKNS6_3ExpIT3_SB_XT4_EEE+0x79) [0x7f881d6388a9]
[bt] (3) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(ZN5mxnet2op6CropOpIN7mshadow3gpuEE8BackwardERKNS_9OpContextERKSt6vectorINS_5TBlobESaIS9_EESD_SD_RKS8_INS_9OpReqTypeESaISE_EESD_SD+0x25f) [0x7f881e5c104f]
[bt] (4) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(ZN5mxnet2op13OperatorState8BackwardERKNS_9OpContextERKSt6vectorINS_5TBlobESaIS6_EERKS5_INS_9OpReqTypeESaISB_EESA+0x2c7) [0x7f881d27c4d7]
[bt] (5) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet4exec23StatefulComputeExecutor3RunENS_10RunContextEb+0xbb) [0x7f881d09259b]
[bt] (6) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(+0x26c58e7) [0x7f881d0978e7]
[bt] (7) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet6engine14ThreadedEngine15ExecuteOprBlockENS_10RunContextEPNS0_8OprBlockE+0x9d) [0x7f881d079cbd]
[bt] (8) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet6engine23ThreadedEnginePerDevice9GPUWorkerILN4dmlc19ConcurrentQueueTypeE0EEEvNS_7ContextEbPNS1_17ThreadWorkerBlockIXT_EEESt10shared_ptrINS0_10ThreadPool11SimpleEventEE+0x103) [0x7f881d07de13]
[bt] (9) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(ZNSt17_Function_handlerIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEZZNS2_23ThreadedEnginePerDevice13PushToExecuteEPNS2_8OprBlockEbENKUlvE1_clEvEUlS5_E_E9_M_invokeERKSt9_Any_dataS5+0x56) [0x7f881d07e016]
A fatal error occurred in asynchronous engine operation. If you do not know what caused this error, you can try set environment variable MXNET_ENGINE_TYPE to NaiveEngine and run with debugger (i.e. gdb). This will force all operations to be synchronous and backtrace will give you the series of calls that lead to this error. Remember to set MXNET_ENGINE_TYPE back to empty after debugging.
Stack trace returned 8 entries:
[bt] (0) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN4dmlc15LogMessageFatalD1Ev+0x3c) [0x7f881b214acc]
[bt] (1) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet6engine14ThreadedEngine15ExecuteOprBlockENS_10RunContextEPNS0_8OprBlockE+0x3a0) [0x7f881d079fc0]
[bt] (2) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZN5mxnet6engine23ThreadedEnginePerDevice9GPUWorkerILN4dmlc19ConcurrentQueueTypeE0EEEvNS_7ContextEbPNS1_17ThreadWorkerBlockIXT_EEESt10shared_ptrINS0_10ThreadPool11SimpleEventEE+0x103) [0x7f881d07de13]
[bt] (3) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(ZNSt17_Function_handlerIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEZZNS2_23ThreadedEnginePerDevice13PushToExecuteEPNS2_8OprBlockEbENKUlvE1_clEvEUlS5_E_E9_M_invokeERKSt9_Any_dataS5+0x56) [0x7f881d07e016]
[bt] (4) /usr/local/lib/python2.7/dist-packages/mxnet-0.12.0-py2.7.egg/mxnet/libmxnet.so(_ZNSt6thread5_ImplISt12_Bind_simpleIFSt8functionIFvSt10shared_ptrIN5mxnet6engine10ThreadPool11SimpleEventEEEES8_EEE6_M_runEv+0x3b) [0x7f881d07b25b]
[bt] (5) /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xb1a60) [0x7f8835789a60]
[bt] (6) /lib/x86_64-linux-gnu/libpthread.so.0(+0x8182) [0x7f883b431182]
[bt] (7) /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f883b15e47d]

Have you re-install mxnet python interface?
Try run python setup install --user in mxnet/python/

@huangzehao Thank you!  I found the question about root privileges of python, and bash scripts/train_alternate.sh , continue training now .

@huangzehao
Thanks, the problem has been solved. But I think the loss of value is a bit strange.
RCNNLogLoss=nan,        RCNNL1Loss=nan, and the MaskACC is very high at the beginning.
INFO:root:Epoch[0] Batch [2440] Speed: 0.54 samples/sec Train-RCNNAcc=0.752260, RCNNLogLoss=nan,        RCNNL1Loss=nan, MaskACC=0.909043,      MaskLogLoss=0.187292,
INFO:root:Epoch[0] Batch [2460] Speed: 0.55 samples/sec Train-RCNNAcc=0.752241, RCNNLogLoss=nan,        RCNNL1Loss=nan, MaskACC=0.909081,      MaskLogLoss=0.187062,
INFO:root:Epoch[0] Batch [2480] Speed: 0.57 samples/sec Train-RCNNAcc=0.752234, RCNNLogLoss=nan,        RCNNL1Loss=nan, MaskACC=0.909107,      MaskLogLoss=0.186841,
[18:18:51] src/operator/././cudnn_algoreg-inl.h:112: Running performance tests to find the best convolution algorithm, this can take a while... (setting env variable MXNET_CUDNN_AUTOTUNE_DEFAULT to 0 to disable)
[18:18:51] src/operator/././cudnn_algoreg-inl.h:117: If you see this message in the middle of training, you are probably using bucketing. Consider setting env variable MXNET_CUDNN_AUTOTUNE_DEFAULT to 0 to disable cudnn tuning.
INFO:root:Epoch[0] Batch [2500] Speed: 0.49 samples/sec Train-RCNNAcc=0.752235, RCNNLogLoss=nan,        RCNNL1Loss=nan, MaskACC=0.909166,      MaskLogLoss=0.186595,
INFO:root:Epoch[0] Batch [2520] Speed: 0.52 samples/sec Train-RCNNAcc=0.752217, RCNNLogLoss=nan,        RCNNL1Loss=nan, MaskACC=0.909197,      MaskLogLoss=0.186370,

@994374821 I had the same problem here.

Hi, @994374821
Could you provide your training configuration?
The learning rate should be adjusted by the number of gpu used for training.

sure @huangzehao
in the train_alternate.sh:
python train_alternate_mask_fpn.py
--network resnet_fpn
--dataset ${DATASET}
--image_set ${SET}
--root_path ${TRAIN_DIR}
--pretrained model/resnet-50
--prefix ${TRAIN_DIR}
--pretrained_epoch 0
--gpu 1
The rcnn_lr uses default.rcnn_lr.The problem occures when I train the first stage of rcnn.

Try divide the learning rate by 4.

Are you debug mode? I use release mode to recompile the source to solve the problem.

after cp rcnn/CXX_OP/* incubator-mxnet/src/operator/,then compile, the errors occuring as follow.
src/operator/./roi_align_v1-inl.h:336:9: error: ‘Fill’ was not declared in this scope
Fill(s, outputs[0], kWriteTo, static_cast(0));
^
/home/user/zhufan-mask/mx-maskrcnn/incubator-mxnet/mshadow/mshadow/./base.h:907:8: note: in definition of macro ‘MSHADOW_REAL_TYPE_SWITCH’
{VA_ARGS}
^


Fix macos nullptr issue

Note that this seems to be an issue with Clang not using C++ 11 standards.  While I don't know this flag is necessary, I don't use Mac nor Clang so I have no way of knowing.


Inherited test methods do not get expected group behavior

Consider the following test classes:
@Test
public abstract class ParentTest {
	public void parentTestMethod() {
	}
}

@Test(groups = "myGroup")
public class ChildTest extends ParentTest {
	public void childTestMethod() {
	}
}

When running this test (ChildTest), I would expect that both test methods (childTestMethod and parentTestMethod) belong to group 'myGroup'. Apparently this is not the actual behavior (tested with version 6.4).
I put together some code to investigate this issue:
TestNGMethodFinder testNGMethodFinder = new TestNGMethodFinder(new RunInfo(), new JDK15AnnotationFinder(new DefaultAnnotationTransformer()));
ITestNGMethod[] testMethods = testNGMethodFinder.getTestMethods(ChildTest.class, new XmlTest());
for (ITestNGMethod testMethod : testMethods) {
	String[] groups = testMethod.getGroups();
	System.out.println(testMethod + " groups:" + Arrays.toString(groups));
}

Output from running this code:
ChildTest.childTestMethod()[pri:0, instance:null] groups:[myGroup]
ParentTest.parentTestMethod()[pri:0, instance:null] groups:[]

I looked into the TestNG source code, and it appears that this behavior originates from the method org.testng.internal.BaseTestMethod#initGroups(Class<?>). To be exact, I think the following statement is the cause of this rather odd behavior:
ITestOrConfiguration classAnnotation = (ITestOrConfiguration) getAnnotationFinder().findAnnotation(getMethod().getDeclaringClass(), annotationClass);

In order to fix this issue, this statement could be modified to:
ITestOrConfiguration classAnnotation = (ITestOrConfiguration) getAnnotationFinder().findAnnotation(getInstance().getClass(), annotationClass);

but I am not sure if this would be the correct way to resolve the issue. Nor eventual implications....

I see the problem, and your suggestion doesn't quite work, unfortunately. It's a bit tricky to solve because annotations are resolved in the init phase, which means that when the parent's @Test annotation is parsed, it obviously knows nothing about the fact that the child annotation will add more groups to it...

Cedric, thank you for your prompt feedback on this issue. You say "it is a bit tricky to solve", does that mean that you do not think that this issue will have a chance of being resolved in the near future? Can you think about any possible workarounds?

What I meant was: when the group resolution is performed, no test class has been instantiated yet, so when I look at parentTestMethod(), I don't have an instance of ChildTest that would allow me to put that method in this group.
Group resolution is purely static, while the example above can only be resolved dynamically.
Does this make sense?

I created a custom method selector, that uses the groups from subclass Test annoation
/* *****************************************************************************

Copyright 2017 VMware, Inc.  All rights reserved. VMware Confidential
****************************************************************************/
package com.vmware.cloud.systemtests.util;

import java.util.Arrays;
import java.util.List;
import org.apache.commons.lang3.ArrayUtils;
import org.testng.IMethodSelector;
import org.testng.IMethodSelectorContext;
import org.testng.ITestNGMethod;
import org.testng.annotations.Test;
import org.testng.xml.XmlTest;
/**

Selector that uses groups in subclass @Test annotations to determine if methods should be included
*/
public class SubclassAwareXmlMethodsSelector implements IMethodSelector {
@Override
public boolean includeMethod(IMethodSelectorContext context, ITestNGMethod method, boolean isTestMethod) {
XmlTest xmlTest = method.getXmlTest();
if (xmlTest == null) {
return method.isAlwaysRun();
}
Class realTestClass = isTestMethod ? method.getTestClass().getRealClass() : method.getRealClass();
Test testClassAnnotation = (Test) realTestClass.getAnnotation(Test.class);
String[] classAnnotationGroups = testClassAnnotation != null ? testClassAnnotation.groups() : new String[0];
List groups = Arrays.asList(ArrayUtils.addAll(classAnnotationGroups, method.getGroups()));
 context.setStopped(true);
 if (groups.size() == 0 && xmlTest.getIncludedGroups().isEmpty()) {
     return true;
 } else if (groups.size() > 0 && xmlTest.getExcludedGroups().stream().anyMatch(groups::contains)) {
     return false;
 } else if (groups.size() > 0 && xmlTest.getIncludedGroups().stream().anyMatch(groups::contains)) {
     return true;
 } else {
     return method.isAlwaysRun();
 }

}
@Override
public void setTestMethods(List list) {
}
}


Target=Host: Remove -m32 for non MINGW builds

Remove -m32 (32 bit compile) for non MINGW builds.
Update to typedef std::uint64_t value_type in mcal_gpt.h resolves this.

Very good catch on a hard to find error. Thx.


WIP: Upgrade Tokio to 1.0 version

This PR is just indicate I'm trying upgrade the tokio to 1.0 version, It's NOT ready for MERGE.
Currently blocked by tokio lack of Stream trait

closed by https://github.com/hecrj/iced/pull/672


session.record should work with peakbagging results

Currently only stores the asymptotic mode id results, and the figures.

Do we still want a record function? Might want to have a generic recording class that works for all the steps. I'll close this for now.


Allow fnametruncate to trucate the buffer name from the beginnning

The current airline#extensions#tabline#fnametruncate will truncate the filename from the end. It's very inconvenient because the file extension will be truncated as well.
I would like to request a new option to truncate the extension from the beginning.
Any thoughts?

PR appreciated

I am closing this in favor to the new PR ;)

awesome! which one?


Add Traffic Sign Recognition model, Fixes #293

Added a traffic sign recognition project.
Issue No: #293

Added a traffic sign recognition project. Issue No: #293

I am unable to view your all files due to restrictions. Is it running on your system without fail?.

Yes, they are!

Can you please check now?


fix: fix some theme style issues.

Summary
This pr fix theme style issues when navbar or outline not display.

change css variable --rp-aside-width and --rp-sidebar-width from 0 to 0px

while chrome tract calc(100% - 0px) as invalid property value

move sidebar padding property to a sub container

while sidebar width set to 0 still has padding-right remind.

.rspress-doc and .rspress-doc-footer change box-sizing: content-box to box-sizing:border-box in screen 1280px because of content-width + padding > 100vw

increase outline max-height for reduce the gap between outline bottom and page bottom.

Related Issue

Checklist

[ ] I have added changeset via pnpm run change.
[ ] I have updated the documentation.
[ ] I have added tests to cover my changes.

@sumy7 Hi, the content width is wired after this PR (in my 14-inch mac), can you take a look?

https://rsbuild.dev/guide/advanced/env-vars

Hi, @chenjiahan I've taken a look at the issue you mentioned.
This is due to the width of rspress-doc being set to calc(100vw - var(--rp-aside-width) - var(--rp-sidebar-width)).
However, due to the flex layout, the width of the rspress-doc's parent container and the sidebar have been redistributed, causing the actual width of the sidebar to not reach the specified width.
One solution is to set the parent container of rspress-doc to flex:1, and also appropriately reduce the width of the sidebar.
I will attempt to fix this styling issue.

Thanks! ❤


fix: remove example summary from template

Hey @sinaatalay,
thank you for this amazing tool, I am really liking what I have seen so far! Just a minor fix since I was experimenting with the latest code changes from master.
I tried to infer what the correct template should look like from your other changes. I hope it is correct.
Best,
Tom

Judging from the tests, not quite... but at least with my demo CV the summary worked fine with version 1.6, but now only includes the sample summary that is currently in the classic/TextEntry.j2.tex template.

Thank you for finding this! Your approach was spot on. I am merging it.
The tests failed due to mismatches between the RenderCV's output and reference outputs in the testdata folder. Since a template has been updated, indeed, the reference outputs in the testdata folder should also be updated.
A note about tests:
In some of the tests:

RenderCV generates an output with a sample input.
Then, the output is compared with a reference output, which has been manually generated and stored in testdata. If the files differ, the tests fail.

When the testdata folder needs to be updated, it can be manually regenerated by setting update_testdata to True in conftest.py and running the tests.
Whenever the testdata folder is generated, the files should be reviewed manually to ensure everything works as expected. But sometimes, mistakes like this one can go unnoticed. Therefore, any ideas about other testing approaches would be appreciated.


Using PSF real image rather than 6 parameter model degrades sleep performance

This was surprising to me, following #316 I tested the sleep phase on the PSF image at the center of the stripe-82 frame (obtained from the psf_at_points function) and the performance was degraded (the loss that the model converged to wasn't as low as before). To be more specific, the metrics that were related to fluxes all got severely impacted, so there appears to be something off with the flux estimation after this change (most of the other metrics improved a little or stayed the same)
I don't know the reason for this and perhaps this requires a more thorough follow-up investigation. I'm going to probably leave this for now as an issue, address it later, and use whatever works best for BLISS.

Closed during meeting


Update product name, cleanup annotations

Codecov Report

Merging #13 (8da49ba) into master (3b49e48) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #13   +/-   ##
=======================================
  Coverage   96.75%   96.75%
=======================================
  Files           4        4
  Lines         154      154
=======================================
  Hits          149      149
  Misses          5        5

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 3b49e48...8da49ba. Read the comment docs.


Fix/negative quantification color

https://www.pivotaltracker.com/story/show/157551941

Show Negative BAU points in the right color
Frame Not quantifiable range into data minimum and maximum

https://basecamp.com/1756858/projects/13795275/todos/332083809

GHG emissions: Smooth the chart lines in all cases except for the UNFCCC data

https://basecamp.com/1756858/projects/13795275/todos/349822479

Smooth lines in ESP (Using monotone type). It can't be smoother while still being accurate.

Extra:

Huge needed refactor extracting the logic of the stack-area-component, creating selectors and breaking the different parts in the component (last point, quantification points, labels, ...)
Dockerfile conflicts with sandbox fixed

Thanks @simaob, that is fixed in Fix domain commit

Most issues are gone, but there's one small one with mismatch between the graph and the legend, for these countries:

http://localhost:3000/countries/BTN
http://localhost:3000/countries/MDV

the legend for "Non quantifiable target", is not showing.


Cannot find name 'ErrorOptions'.

Hi,
via
"@zxing/library": {
"version": "0.19.1",
"resolved"<EMAIL_ADDRESS>"integrity": "sha512-rKwvl3Uuqs8yf364iU9l3HDDaIx8yPv+CH6DbtQaQr67VdKLG22G1ukEp9fOdDefE6tpLtRAdMnTrgtpiaKAZw==",
"requires": {
"@zxing/text-encoding": "~0.9.0",
"ts-custom-error": "^3.0.0"
}
},
i got a new
      ERROR in node_modules/ts-custom-error/dist/custom-error.d.ts:3:45 - error TS2304: Cannot find name 'ErrorOptions'.

today.
i can't find any ErrorOptions class here and the github universe, please help,
thanks

3.3.0 is  a bugged new  version  released

Same issue here :)

Sooooory, please, rollback to 3.2.2 or add "ES2022" & "ES2022.error" in your tsconfig.json lib array. thanks @f-mon for the quick & efficient solution.

package.json
"ts-custom-error":"3.2.2",
and all is fine again ..

I've deprecated version 3.3.0 , put back the 3.2.2 as current version.

I'll see how to fix properly this issue with a 3.3.1 version ASAP

@ohonigx

i can't find any ErrorOptions class here and the github universe, please help,

it's from  https://github.com/microsoft/TypeScript/blob/main/lib/lib.es2022.error.d.ts
yep, it's a thing ;)
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause
https://v8.dev/features/error-cause
But now I have to find an elegant way to introduce it without breaking your builds ;)

@ohonigx

But now I have to find an elegant way to introduce it without breaking your builds ;)

:-) Thanks to the others here i solved it with the new entry in package.json "ts-custom-error":"3.2.2", so the zxing/library is happy again. Thanks for your work and the fast reponse!

Hi, @adriengibrat
we use dependency  "@zxing/ngx-scanner": "3.0.0", which still creates the following in package_lock.json`:
"@zxing/library": {
"version": "0.15.2",
"resolved"<EMAIL_ADDRESS>"integrity": "",
"requires": {
"text-encoding": "^0.7.0",
"ts-custom-error": "^3.0.0"
},
"dependencies": {
"ts-custom-error": {
"version": "3.3.0",
"resolved": "https://registry.npmjs.org/ts-custom-error/-/ts-custom-error-3.3.0.tgz",
"integrity": ""
}
}
},
"@zxing/ngx-scanner": {
"version": "3.0.0",
"resolved"<EMAIL_ADDRESS>"integrity": "",
"requires": {
"@zxing/library": "^0.15.1",
"tslib": "^1.9.0"
},
"dependencies": {
"tslib": {
"version": "1.14.1",
"resolved": "https://registry.npmjs.org/tslib/-/tslib-1.14.1.tgz",
"integrity": ""
}
}
},

Seems it still considers 3.3.0 as the latest.
I tried npm i ts-custom-error in some other place and it still shows,
"dependencies": {
"ts-custom-error": "^3.3.0",
}
I think it still recognize 3.3.0 as latest.

Hello I have the same problem as @RandulaKoralage . We use @@zxing/ngx-scanner which underneath uses @zxing/library which uses "ts-custom-error": "^3.0.0". Therefore I cannot edit this dependency
On my rather new npm it is handled correctly, i.e. deprecated module is skipped and last correct version is installed.
However, on other place where my npm is quite old and I cannot update, it keeps taking the deprecated version and therefore the build fails
Could you completely remove the version 3.3.0 from npm? If the lib is broken then it does not help anyone. Do I understand it correctly?
Regards
Antoni

in React, @zxing/library still installs 3.3.0, so I installed "ts-custom-error" v3.2.2 as a dev dependency.
npm i -dev<EMAIL_ADDRESS>

For all those who still have issue because dependency tree still install 3.3.3,
you may try to
upgrade typescript >=4.6
& add :
"lib: [...,"ES2022", "ES2022.error"],
in your tsconfig.json
see https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-6.html#--target-es2022

I've released a 3.3.1 version where i copy the typescript ErrorOption interface to avoid the error, I hope this should definitively fix the issue.

Please, confirm the 3.3.1 compiles on your projects, then i'll close the issue.

My build works again! :) thank you

Finally! @adriengibrat my build also worked. Thank you.

OK, it's fixed. Thanks for your feedback.


Figma File Search fails to provide access to raycast

Extension
https://www.raycast.com/michaelschultz/figma-files-raycast-extension
Raycast Version
1.79.1
macOS Version
14.5
Description
I tried to link my Figma team to the Figma extension, I had to sign in via my browser and when I returned to raycast I had an error
Error:
FetchError: request to https://oauth.raycast.com/v1/token/qTlHR2nhUt2e07Ynlbw-T4ALSoDPrGnUZU4z1VsH-scRq-We8cI9RfPKJb9UfEau0bCVYIc0qtW5fOVJ0rtUwDN6KSg5d8XgR_wRofMYARLRzAWhTb5mFsXTdFZl3GPQfA failed, reason: unable to get local issuer certificate

    at withAccessToken(A5)
_r:index.js:8:2593
    at ray-navigation-stack
Eo:index.js:8:2094

Steps To Reproduce
With above raycast and macOS
Select "Search Files" command from Figma extension
In Connect your Figma account screen click Sign in with Figma
In this screen

Click allow access
In this screen

click open to raycast (I had to use button chrome provided rather the one in the webpage)
See this screen

Current Behaviour
see error message
Expected Behaviour
Figma account would be linked and would be able to search files

@Gareth71 thanks for reporting. Have you also added your team ID in the extension settings?
Appreciate the in-depth report btw. I think a few of the small bugs you ran into are Raycast issues and I'll pass them along.

Yes, I added my teams id following the instructions I found from a website I googled (see below). I checked and I can see it in the extensions settings.GarethOn 20 Jul 2024, at 5:56 PM, Michael Schultz @.***> wrote:
@Gareth71 thanks for reporting. Have you also added your team ID in the extension settings?
Appreciate the in-depth report btw. I think a few of the small bugs you ran into are Raycast issues and I'll pass them along.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

I'm having the same issue. After entering the team ID, clicking "sign in with figma" button, and then allowing access, I just get the "something went wrong" message. If I had to guess there may be an issue with our Figma SSO / security settings that is preventing this from working. Even as a Figma admin in my org I don't see a way to add Raycast to the "connected apps" list within Figma's settings.

@thomaspaulmann mind weighing in here?


AttributeError: module 'asyncio' has no attribute 'coroutine'

Hi, after migrating to HA 2023.6.0, asyncio error popped up.
Platform error: vacuum
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/loader.py", line 833, in get_platform
    cache[full_name] = self._import_platform(platform_name)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/loader.py", line 850, in _import_platform
    return importlib.import_module(f"{self.pkg_path}.{platform_name}")
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1206, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1178, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1149, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 940, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/config/custom_components/lg_hombot/vacuum.py", line 53, in <module>
    @asyncio.coroutine
     ^^^^^^^^^^^^^^^^^
AttributeError: module 'asyncio' has no attribute 'coroutine'

Hi, the issue is most likely related to the new Python version. I will take a look at it on Saturday or Sunday and release a new version :)

Thank you very much for your efficiency.
Works on version 2023.06.1. You plan to display attributes JSON (lastclean, state, speed, mode. repeat)? Is it possible to get an image from the robot's camera in HA?


add command handler to uncatch keyboard event if search is closed

Fixes #3929
Added a check to see if searchbox is open before dispatching the SESSION_SEARCH_CLOSE action and set catched to false if it isn't so that xterm is able to receive it.
Doing it by using a command handler, had to provide dispatch to command handlers for this to work.
Do test it out to see if it's working properly, and not impacting any plugins.

Worked well here, thank you!


Adding a URL Shortener App

Describe the solution you'd like
I will add an attractive url shortner app

The same Issue added here already #491


Manual review request: add usd-coin coingeckoId to USDC-Dev devnet token

I'm submitting a ...
[x] manual review request (per README)

Summary

PR: https://github.com/solana-labs/token-list/pull/21342

The token USDC-Dev is supposed to act like USDC in Devnet for testing purposes
I've added the USDC coingeckoId so that wallets will display its value using USDC

merged


SyncEngine.performSync fetches all messages from peer

What is the bug?
SyncEngine.performSync() fetches all messages from peer even it already has all the messages.
How can it be reproduced? (optional)
Test case snippet:
 const engine1 = new Engine(testDb, FarcasterNetwork.FARCASTER_NETWORK_TESTNET);
 const syncEngine1 = new SyncEngine(engine1, testDb);
 const engine2 = new Engine(testDb2, FarcasterNetwork.FARCASTER_NETWORK_TESTNET);
 const syncEngine2 = new SyncEngine(engine2, testDb2);

 await engine1.mergeIdRegistryEvent(custodyEvent);
 await engine1.mergeMessage(signerAdd);
 await engine2.mergeIdRegistryEvent(custodyEvent);
 await engine2.mergeMessage(signerAdd);

 const messages = await addMessagesWithTimestamps([30662167, 30662169, 30662172], engine1);
 for (const message of messages) {
   await engine2.mergeMessage(message);
 }

 // Sanity check, they should equal
 expect(await syncEngine1._trie.rootHash()).toEqual(await syncEngine2._trie.rootHash());

 Date.now = () =><PHONE_NUMBER>000 + 30662200 * 1000;

 const snapshot2 = (await syncEngine2.getSnapshot())._unsafeUnwrap();
 // Bug 1
 expect((snapshot2.prefix as Buffer).toString('utf8')).toEqual('00306622');

 const rpcClient = new MockRpcClient(engine2, syncEngine2);
 await syncEngine1.performSync(snapshot2.excludedHashes, rpcClient as unknown as HubRpcClient);

 expect(rpcClient.getAllSyncIdsByPrefixCalls.length).toEqual(1);
 // Bug 2
 expect(rpcClient.getAllSyncIdsByPrefixCalls[0].prefix.toString('utf8')).toEqual('');

// Fetch all SyncIds as a result
 expect(rpcClient.getAllMessagesBySyncIdsCalls.length).toEqual(1);
 expect(rpcClient.getAllMessagesBySyncIdsCalls[0].syncIds.length).toEqual(4);

Complete test case: https://github.com/kcchu/hub/commit/2f012cb7c9031c19b4bf545dd230b4fca09e0094
This bug requires the fix in https://github.com/farcasterxyz/hubble/pull/535 to be applied.
Additional context (optional)
The issue is composed of (at least) 2 bugs in the SyncEngine.
Bug 1:
The prefix returned by MerkleTrie.getSnapshot() could point to an non-existent node. This behavior is demonstrated in one of the existing test cases https://github.com/farcasterxyz/hubble/blob/03113792084e028d2542f30c69d99fc3efa8e7c2/apps/hubble/src/network/sync/merkleTrie.test.ts#L432-L439
The above test case returns a non-existent node 167. It is unclear whether it is intentional. However, this behavior causes MerkleTrie.getDivergencePrefix() to return the non-existent prefix when two tries has the same excluded hashes.
Bug 2:
Bug 1 further causes performSync function to misbehave.
performSync calls fetchMissingHashesByPrefix with divergencePrefix:
https://github.com/farcasterxyz/hubble/blob/03113792084e028d2542f30c69d99fc3efa8e7c2/apps/hubble/src/network/sync/syncEngine.ts#L210-L226
fetchMissingHashesByPrefix calls RPC function getSyncMetadataByPrefix. Since the divergencePrefix does not exist, the RPC function returns an empty node (not error).
fetchMissingHashesByPrefix  then calls fetchMissingHashesByNode:
https://github.com/farcasterxyz/hubble/blob/03113792084e028d2542f30c69d99fc3efa8e7c2/apps/hubble/src/network/sync/syncEngine.ts#L187-L199
theirNode is empty, so it falls into the case at line 187 which calls getAllSyncIdsByPrefix with an empty prefix (from the empty node).
From here, SyncEngine fetches all messages from the peer.

Let me think about Bug 2, but at least for Bug 1, I think we should change behaviour so that fetching a non-existing timestamp returns the highest valid node. i.e.,
   const snapshot = await trie.getSnapshot(Buffer.from('1677123'));
   expect(snapshot.prefix).toEqual(Buffer.from('16'));

It should return the "16" node, which is the highest node that is actually available. This satisfies the original reason this was added: When fetching a timestamp that may not have any messages, fetch the closest timestamp that does have messages, so clients can decide whether to sync.

Here are some things we can maybe do, I'm curious to hear what you think:

I think getSyncMetadataByPrefix should not accept an empty Prefix (i.e. root node) as a parameter. That's likely to be a bug in any situation, so we should fail that. Same for getAllSyncIDsByPrefix
I think your idea that getDivergencePrefix to take into account the snapshot prefix is a good one. How exactly do you think it should work?
If getDivergencePrefix returns a empty node, we should abort the sync and retry later, which will prevent unnecessary message fetching.

I'm curious to hear your thoughts, too.

Ok, I fixed some of the prefix issues, but I'm still a bit confused about the core of this bug.
Let's assume the worst case scenario - That the divergencePrefix is the root node (i.e empty node) or a non-existent node, and fetchMissingHashesByPrefix gets called with that.
However, as it starts recursing into the trie in fetchMissingHashesByPrefix and fetchMissingHashesByNode, the sync algorithm will figure out that the hashes at various levels actually match, and won't fetch any messages. (See https://github.com/farcasterxyz/hubble/blob/main/apps/hubble/src/network/sync/syncEngine.ts#L224)
The only thing that can happen is it will fetch HASHES_PER_FETCH =50 messages if the root node has less than that many messages, which seems fine.
Even the getSyncMetadataByPrefix, which gets the metadatas, it will only fetch one level before it realizes that the child hashes match.

In any case, I added some more checks in fetchMissingHashesByPrefix, so that even if the divergence or node is bad, it won't unnecessarily fetch messages. Also handles the case where pruning removes messages on the other node before ours.
In https://github.com/farcasterxyz/hubble/pull/540


Allow to fail Pharo 7

Coverage remained the same at 99.899% when pulling 6d5ac7d0d00df57945ccf53f0b178b3c34214710 on allowed_failures_ci into b8a2f73cc04c806badb4d702908eb7a0bee2a885 on master.

Coverage increased (+0.02%) to 99.917% when pulling 7048b2d3123d27868ba0e4cb135fc555a8f48bcd on allowed_failures_ci into b8a2f73cc04c806badb4d702908eb7a0bee2a885 on master.

Coverage increased (+0.02%) to 99.917% when pulling b361e6e6f2fb95d554cce5b6566795225ffcd59d on allowed_failures_ci into b8a2f73cc04c806badb4d702908eb7a0bee2a885 on master.

Coverage increased (+0.02%) to 99.917% when pulling b361e6e6f2fb95d554cce5b6566795225ffcd59d on allowed_failures_ci into b8a2f73cc04c806badb4d702908eb7a0bee2a885 on master.

Coverage increased (+0.02%) to 99.917% when pulling ba5531cb82410d8a48fc47b34fda4e17807690f7 on allowed_failures_ci into b8a2f73cc04c806badb4d702908eb7a0bee2a885 on master.


add back the L1 <-> L2 tests

We're removed those tests in https://github.com/snapshot-labs/sx-starknet/pull/620
Would be nice to add them back, or rework them

Should be back on , thanks to @ivpavici


Capitalize EGOIST

this is a convention of my (nick)name 😎😂

I just updated this on the master branch. 👍


MXKContact: Add hasPrefix method

Tell whether a component of the contact's displayName, or one of his matrix id/email has the provided prefix.

LGTM


MonacoWebpackPlugin version issue

env = win10, node=13.7.0
run flow :  npm run build-dll
error message :  Error: Cannot find module 'monaco-editor\esm\vs\editor\contrib\gotoSymbol\goToCommands'
after tracing, the monaco-editor-webpack-plugin package is removed the related feature gotoSymbol
suggestion :
ignore the issue by adding features: ['!gotoSymbol'], if there are no dependence on the feature.
@webpack.config.base.js , line42~48
 plugins: [
    new MonacoWebpackPlugin({
      // available options are documented at https://github.com/Microsoft/monaco-editor-webpack-plugin#options
      languages: ['pgsql'],
      features: ['!gotoSymbol'], // <<- add this
    }),
  ]

Hi @Stvchm9703!
Thanks for the report, but I can't reproduce it. How did you install dependencies? Did you use yarn or npm?

I just run npm i and npm i -D

I think that's the cause of the issue. Try to use yarn: npm ignores yarn.lock.
By the way, why do you want to use dev version of the app? Would be interesting to know.

😆  since the developing environment of my project is Window 10, and there are no release version of window in this project. Therefore, try and run

You can try to build production version with yarn && yarn package.
Or development version with yarn && yarn dev.
I think it should work. Tell me if you'll face any issues!

Thanks for replying, cheers 🥂


If log file does not exists, error goes to 'last 10 lines of log' with process prefix, and it looks like error in logs of process

fixed @0.0.19


Fix issue 1124: Segmentation fault when using specific tables

This is a fix for issue 1124 -
Segmentation fault when using specific names for tables.
This issue is due to an oversight of some very specific types of tables that are parameterless functions. The logic to walk through these nodes didn't expect them and would crash due to them.
This fix adds in code to skip over these types of tables.
Added regression tests.

Looks good to me.


option to configure agent sds

Not sure if this is the preferred way. Could also populate the values file with defaults from https://github.com/spiffe/spire/blob/main/doc/spire_agent.md#sds-configuration

Hi @grameshtwilio thanks for the submission. Populating the values with defaults is preferred, but we understand people are busy. If you are able to do that, then great. If not we can take the changes as is and fill them in later.

Also note we have a major docs refactor we are hoping to merge next. There might be some merge conflicts here when you update after than one is merged.

Also note we have a major docs refactor we are hoping to merge next. There might be some merge conflicts here when you update after than one is merged.

I'll keep an eye on it and rebase/alter this PR to incorporate the new format.


onnx quantization

Thanks for your code!

Hi,
the ONNX quantization feature is relatively new as far as I know. I don't have any experience with it yet. From a quick look I would say, that is still need time to develop and I think LSTMs can not be quantized yet.


@forelse() directive indentation

in @forelse blade directive @empty not indent correctly.
Should be :
@forelse()

@empty

@endforelse

Currently formatted like :
@forelse()

         @empty

         @endforelse

Other informations
I am using Laravel Blade formatter v0.14.2
Is this a bug or impropper configurations of the settings ?

@GDC-Nirmal
I tried formatting it with the following code, but I couldn't reproduce it

@forelse($users as $data)

@empty

@endforelse

will format into

        @forelse($users as $data)

        @empty

        @endforelse

It might be caused by other parts of template, so can you post the whole template? Thanks.

my original code is large (1100+ lines).
I created example code.
@extends('layouts.app_user')

@section('content')

                    #
                    Username
                    Price
                    Action

                @forelse ($users as $user)

                        {{ $loop->iteration }}

                            {{-- check if-else directive causes the problem --}}
                            @if ($user->username)
                                {{ $user->username }}
                            @else
                                {{ $user->email }}
                            @endif

                            {{-- check custom blade component causes the problem --}}
                            <x-price-preview price="{{ rand(100, 100000) }}" />

                            <button class="btn btn-sm btn-primary" data-toggle="collapse"
                                data-target="#moreFoodInfo{{ $user->id }}" aria-expanded="false"
                                aria-controls="moreFoodInfo{{ $user->id }}">

                            </button>

id }}">

                                                        #

                                                        Permission

                                                        Status

                                                @if (!empty($user->permissions))
                                                    @forelse ($user->permissions as $permission)

                                                                {{ $loop->iteration }}

                                                                {{ $permission->name }}

                                                                {{ $permission->statusAsString() }}

                                                    @empty

                                                                No Permissions

                                                    @endforelse
                                                @endif

                    @empty

                            No Users

                    @endforelse

    @endsection

I don't see any issue with the code.

It seems this happens when @forelse~@empty~@endforelse directive exists in nested @forelse ~ @if ~ @endif ~ @empty ~ @endforelse
minimum reproduceable code
@forelse($users as $user)
    @if ($user)
        aaa
        @forelse($users as $user)
            foo
        @empty
            bar
        @endforelse
    @endif
    aaa
@empty
    aaa
@endforelse

oh I check there if collection variable null instead of empty array.
I will try to avoid using if inside forelse. But I don't know if it is bad usage.
can you fix that ?
This is very good extension. only issue I found is this.
Thank you.

Yes, I just tried a small fix locally and it's probably fixable.
Please wait a little for the release.

Thanks ! @shufo

Fixed at https://github.com/shufo/vscode-blade-formatter/releases/tag/v0.14.3


Change snappy_buffers_test record size for s390x

On s390x the record size for snappy_buffers_test should be 620 bytes.

Given that the implementation of io::SnappyOutputBuffer is not being changed, I don't see why COMPRESSED_RECORD_SIZE needs updating.  The compression algorithm should presumably be architecture agnostic.  My guess is that there is an underlying issue that needs to be resolved.

@cdavoudian Can you please resolve conflicts? Thanks!

Resolved conflicts, still waiting for review & merge. Thanks!

@gharibian Can you please review this PR ? Thanks!

@saxenasaurabh Can you please review this PR ? Thanks!

I don't think we have enough information to move forward with this PR. There is no indication of why the value should be changed nor is there a test to show what this issue fixes. @cdavoudian, could you please address the previous comments from @gharibian?

@cdavoudian  Any update on this PR? Please. Thanks!

@gbaned I am following his up on behalf of @cdavoudian who is no longer involved in this project. Unlike x86, on s390x (big-endian) architecture, snappy compresses the record size to 620 bytes.  This problem was also encounterd in TF v2.0.0.  Reading the testcase comments it appears that snappy can compress this to different sizes based on the implementation.

@jaingaurav Can you please take a look on above comments from @rposts. Thanks!

@rposts: Thanks for the context. Is there any way of validating this new value either by including some header from snappy? Otherwise, is there any test case that can be constructed to fail without this change? At very least please include a link to the documentation in the code, pointing to the different size.

@rposts  Can you please check @jaingaurav's comments and keep us posted ? Thanks!

@gbaned @jaingaurav Apologies for the delay - I will be looking at it shortly. Thx.

@gbaned @jaingaurav - I ran the testcase on x86 and s390x and enclosing my results here.  As you can see, snappy compresses to different sizes on these 2 platforms: The call is made in port.cc:
On x86:
(gdb) p input
$7 = 0x5555556c6ce0 "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce vehicula tincidunt libero sit amet ultrices. Vestibulum non felis augue. Duis vitae augue id lectus lacinia congue et ut purus. Donec auctor, nisl at dapibus volutpat, diam ante lacinia dolor, veldignissim lacus nisi sed purus. Duis fringilla nunc ac lacus sagittis efficitur. Praesent tincidunt egestas eros, eu vehicula urna ultrices et. Aliquam erat volutpat. Maecenas vehicula risus consequat risus dictum, luctus tincidunt nibh imperdiet. Aenean bibendum ac erat cursus scelerisque. Cras lacinia in enim dapibus iaculis. Nunc porta felis lectus, ac tincidunt massa pharetra quis. Fusce feugiat dolor vel ligula rutrum egestas. Donec vulputate quam eros, et commodo purus lobortis sed.Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce vehicula tincidunt libero sit amet ultrices. Vestibulum non felis augue. Duis vitae augue id lectus lacinia congue et ut purus. Donec auctor, nisl at dapibus volutpat, diam ante lacinia dolor, veldignissim lacus nisi sed purus. Duis fringilla nunc ac lacus sagittis efficitur. Praesent tincidunt egestas eros, eu vehicula urna ultrices et. Aliquam erat volutpat. Maecenas vehicula risus consequat risus dictum, luctus tincidunt nibh imperdiet. Aenean bibendum ac erat cursus scelerisque. Cras lacinia in enim dapibus iaculis. Nunc porta felis lectus, ac tincidunt massa pharetra quis. Fusce feugiat dolor vel ligula rutrum egestas.  Fusce vehicula tincidunt libero sit amet ultrices. Vestibulum non felis augue. Duis vitae augue id lectus lacinia congue et ut purus. Donec auctor, nisl at dapibus volutpat, diam ante lacinia dolor, veldignissim lacus nisi sed purus. Duis fringilla nunc ac lacus sagittis efficitur. Praesent tincidunt egestas eros, eu vehicula urna ultrices et. Aliquam erat volutpat. Maecenas vehicula risus consequat risus dictum, luctus tincidunt nibh imperdiet. Aenean bibendum ac erat cursus scelerisque. Cras lacinia in enim dapibus iaculis. Nunc porta felis lectus, ac tincidunt massa pharetra quis. Fusce feugiat dolor vel ligula rutrum egestas. Donec vulputate quam eros, et commodo purus lobortis sed.", 'x' <repeats 9248 times>
(gdb) p length
$17 = 752
(gdb) p outlen
$18 =<PHONE_NUMBER>440
(gdb) n
310       snappy::RawCompress(input, length, &(*output)[0], &outlen);
(gdb)
311       output->resize(outlen);
(gdb) p outlen
$19 = 620

Unfortunately I could not find any headers to prove unless digging deep into snappy code it but I think these results show snappy differences across x86/s390x.  Would this suffice?
Thanks.

@jaingaurav Can you please take a look on above comments from @rposts. Thanks!

@jaingaurav Any update on this PR? Please. Thanks!

@rohan100jain Can you please take a look on this PR ? Thanks!

We relaxed this in 47388e6e562b3589950ec2ae4a5a5e9a5563b916. snappy_test no longer checks for the exact size in the error message.


Change prefixed trie iterator to be limited to prefix. BREAKING

Currently the iteration based on prefix stops at the first key that do not contain a prefix.
This PR change this behavior to stop the iteration at the last key start with the prefix.
This will change all proofs that uses the iteration by prefix, they will contain a few less node (generally one, can be a bit more depending on the depth of next key value that did not start with the prefix).
Therefore this can breaks 'call' light client proof (but it is not use in polkadot or substrate test runtime).
It can also break cumulus witness for runtime using prefixed key iteration (cc @bkchr), but I do not think there is any at this point.
Generally this PR is not a must have, and keeping old iteration could be fine (not sure which version is easier to specify in polkadot specs).
Technical details and tests are at https://github.com/paritytech/trie/pull/39

We currently have prefixed iteration. However by breaking you mean if we had something released?

Yes breaking for something released where proof of call to this prefixed iteration is in use.
I did not see any light client rpc using it directly so it will be only the proof for 'call' of extrinsic, but I did not see use of this prefixed iter for something else than ext clear_prefix and clear_child_prefix which seem used only in kill_prefix, used in double map remove prefix, used in imonline event on_before_session_ending, evm module, staking new_session (non exposed I think) through slashing clear_era_metadata).
So the call proof for light client should only be broken for the evm module (in case such proof is used).
Regarding cumulus this can obviously be in the block transition, so this will break all existing cumulus witness using imonline, evm or staking (friday I overlooked this).
About the testing, there does not seems to be existing tests for this, on the other hand I did write new ones in https://github.com/paritytech/trie/pull/39 , I could probably bring them to substrate to, but I am not sure if it is needed.

I missed a really important call: polkadot set_heads, this could be in theory used in a light client 'call' proof, so this is breaking in the sense that we need a client update.
I am switching the tags, I doubt it is a problem in practice, but it is actually breaking over light client call proof of polkadot for set_heads extrinsics.

Did you tried to sync kusama?

No, this shouldn't break consensus. But it is a small effort to do, I cannot access proper machine today, but could do tomorrow.

No, this shouldn't break consensus. But it is a small effort to do, I cannot access proper machine today, but could do tomorrow.

Yeah that is okay! Just report back :)

Reporting back, did synch kusuma without issue, as expected :)

Ty!


Add PUT support to the content store

Make the content store writeable.
Tasks

[ ] Handles PUT requests
[ ] Validate input
[ ] Send assets to a file store and rewrite their paths

Notes

Can be done synchronously for now.

Links

Content API specification
Base schema

Related

#127 (file API spec)
#131 (eLife-style adapter that will send requests)

Minimal process to be implemented:

The content store validates the Libero-wrapped JATS according to the configured RelaxNG schema
The content store downloads each of the JPEG images
The content store performs a PUT request for each of the JPEG to the object store
The object store persists the images in a publicly available location like an S3 bucket (not a responsibility of this ticket, but for clarity)
The content store replaces the references to images in the Libero-wrapped JATS with the URLs returned by the object store, if possible with the xml:base attribute
The content store persists the Libero-wrapped JATS into its database

The content store downloads each of the JPEG images
The content store performs a PUT request for each of the JPEG to the object store

Could be that the content sends the URI to the object store, which then downloads it.


ci(deps): update terraform-ibm-modules/common-pipeline-assets action to v1.3.1

This PR contains the following updates:

Package
Type
Update
Change

terraform-ibm-modules/common-pipeline-assets
action
patch
v1.3.0 -> v1.3.1

Release Notes

terraform-ibm-modules/common-pipeline-assets
v1.3.1
Compare Source
Bug Fixes

deps: update icr.io/goldeneye_images/goldeneye-ci-image digest to 17225eb (#47) (f7ffab0)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 1.0.14 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


mpl2: support snapping of macros with pins in multiple layers

Resolve #5854.
Attempts to move the macro to different track-grid positions after snapping based on the first layer we find.
First all vertical layers with pins, then all horizontal layers with pins.
The goal is to search for a location that results in the largest number of layers with pins in the same direction to have those pins correctly aligned with the grid.

Took it for a quick spin on https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/2412:
make DESIGN_CONFIG=designs/asap7/mock-array/config.mk

Results in error:
[INFO PPL-0007] Random pin placement.
[WARNING PPL-0106] At least 2 pins in position (42633, 43200), layer M3, port io_ins_down[61].
[ERROR PPL-0107] Invalid pin placement.
Error: io_placement_util.tcl, 11 PPL-0107

@oharboe I believe this is not related to the macro placement. Do you see macros with pins out of track after mpl?

I don't know how to check that...

You can set the tracks visibility in the layout display and then find the pins in the layers you want.
Without the changes here, the pins in some layers were not properly aligned with the grid.
With the changes here we have something like this:

So you shouldn't have the DRCs problems anymore.

Never gets far enough... This might be another manifestation of a problem that I raised with @maliberty ?
Standalone testcase io_placement_problem.tar.gz
$ make DESIGN_CONFIG=designs/asap7/mock-array/config.mk
Running io_placement_random.tcl, stage 2_2_floorplan_io
[INFO ORD-0030] Using 16 thread(s).
[INFO PPL-0048] Restrict pins [ io_ins_up[0] io_ins_up[10] io_ins_up[11] io_ins_up[12] io_ins_up[13] ... ] to region 0.00u-43.20u at the BOTTOM edge.
[INFO PPL-0048] Restrict pins [ io_ins_left[0] io_ins_left[10] io_ins_left[11] io_ins_left[12] io_ins_left[13] ... ] to region 0.00u-43.20u at the RIGHT edge.
[INFO PPL-0048] Restrict pins [ io_lsbOuts_0 io_lsbOuts_1 io_lsbOuts_2 io_lsbOuts_3 io_lsbOuts_4 ... ] to region 0.00u-43.20u at the RIGHT edge.
[INFO PPL-0048] Restrict pins [ clock ] to region 0.00u-43.20u at the TOP edge.
place_pins -hor_layers M2 M4 -ver_layers M3 M5 -random
Found 0 macro blocks.
Using 2 tracks default min distance between IO pins.
[INFO PPL-0007] Random pin placement.
[WARNING PPL-0106] At least 2 pins in position (42633, 43200), layer M3, port io_ins_down[61].
[ERROR PPL-0107] Invalid pin placement.
Error: io_placement_util.tcl, 11 PPL-0107
Command exited with non-zero status 1
Elapsed time: 0:01.09[h:]min:sec. CPU time: user 1.04 sys 0.05 (100%). Peak memory: 217100KB.
make[2]: *** [Makefile:651: do-2_2_floorplan_io] Error 1
make[1]: *** [Makefile:649: results/asap7/mock-array_Element/base/2_2_floorplan_io.odb] Error 2
make: *** [Makefile:351: results/asap7/mock-array_Element/base/Element.lib] Error 2
$ ls results/asap7/mock-array_Element/base/
1_1_yosys.v  1_synth.rtlil  1_synth.sdc  1_synth.v  2_1_floorplan.odb  2_floorplan.sdc  clock_period.txt  keep_hierarchy.tcl  mem.json

@oharboe @AcKoucher The PPL error was fixed last week, but your branch is not updated with the latest master branch. You should not see the PPL issue once you merge the latest master in this PR.

@oharboe @AcKoucher The PPL error was fixed last week, but your branch is not updated with the latest master branch. You should not see the PPL issue once you merge the latest master in this PR.

Indeed.

https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/pull/2412 seems to work fine with this PR+master of OpenROAD. :+1:

secure CI?

@eder-matheus you still have requested change status

Running secure-CI

@eder-matheus @maliberty
Public CI showed some failures:
nangate45 bp_be
      [ERROR DRT-0416] Term w_mask_in[0] contains offgrid pin shape. Pin shape ( 1070263 1136310 ) ( 1070403 1136450 ) is not a multiple of the manufacturing grid 10.

nangate45 bp_fe
      [ERROR GRT-0119] Routing congestion too high. Check the congestion heatmap in the GUI and load ./reports/nangate45/bp_fe/base/congestion.rpt in the DRC viewer.

nangate45 bp_multi
      [ERROR DRT-0416] Term w_mask_in[0] contains offgrid pin shape. Pin shape ( 1872632 45150 ) ( 1872772 45290 ) is not a multiple of the manufacturing grid 10.

nangate45 tinyRocket
      [ERROR DRT-0416] Term w_mask_in[0] contains offgrid pin shape. Pin shape (<PHONE_NUMBER>30 ) (<PHONE_NUMBER>70 ) is not a multiple of the manufacturing grid 10.

These were because for macros that don't have pins to be aligned with the track in a certain direction, we were not aligning with the manufacturing grid.
I pushed a change to ensure that, even we don't need to align to the tracks, we'll still align with the manufacturing grid.
I'll re-run CI.

Secure-CI is fine.


wasme deploy envoy default Envoy image not compatible with Rust SDK

Trying to run wasme deploy envoy with an image built with Rust and the Rust SDK for proxy-wasm crashes with WASM missing malloc/free.
The Rust SDK doesn't expose free, because it is no longer required (see https://github.com/envoyproxy/envoy-wasm/pull/404), but it looks like the default Envoy docker image used (quay.io/solo-io/gloo-envoy-wasm-wrapper:1.3.5) doesn't have this change.
Running with Istio 1.5 proxy works:
wasme deploy envoy <image-name> --envoy-image=istio/proxyv2:1.5.1

thank you! we will update. what filter image are you using to test? i want to make sure there are no other changes.

This one: https://webassemblyhub.io/repositories/150/rust_hello_world
The code is here, if you'd like to have a look: https://github.com/charypar/proxy-wasm-demo.


Doesn't support path with non-ascii characters

As previously mentioned in issue #61, this plugin goes wrong if the imported .scss file makes another import, and if the full path of the latter file contains non-ascii characters. I believe this is a plugin-specific issue as this error doesn't occur with esbuild in general.

As can be seen in the error message here, it somehow escapes the non-ascii characters internally, and therefore the file of course doesn't exists. This error doesn't occur if we only import one .scss file without any further importing inside it.
The current workaround is of course by putting the project in a path consists of ascii characters only, and then everything works fine.

@MuTsunTsai yup...that was another interesting journey!

I've just released v2.2.0 please have a try and let me know how it goes

Damn that was fast! Confirmed issue fixed in v2.2.0 👍

Did you seriously draw a picture just for this issue? LOL


Hide right price scale but show cross hair price

Is it possible to show the cross hair with price but hide the right price scale?

There are some examples here: https://tradingview.github.io/lightweight-charts/tutorials#how-to--examples
Might want to look at the tooltips example.
Price scale Id could be set to '' if you want it to be an overlay (i.e not have a visible price scale) more info


Fix dependencies

Task/Issue URL: https://app.asana.com/0/0/1207493232239625/f
Description
Steps to test this PR
Feature 1

[ ]
[ ]

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

#4613  👈
develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @CrisBarreiro and the rest of your teammates on  Graphite


Unsubscribing to value changes on a dropdown

Stackblitz... please check the comment on line #39
https://stackblitz.com/edit/ngx-formly-ui-bootstrap-nopxgo
Whats the recommended way to unsubscribe to a value changes subscription in formly.
This question has been raised before in https://github.com/ngx-formly/ngx-formly/issues/1664
and answered, but I was unable to see any 'onDestroy' or 'unsubscribe' in the attached answer/example at https://formly.dev/examples/other/cascaded-select
In the example the observable is being passed to an 'optionList' but we are not really unsubscribing anywhere.

export class AppComponent implements OnDestroy {
+  onDestroy$ = new Subject<void>();
  ...
  fields: FormlyFieldConfig[] = [
    {
      key: 'select1',
      type: 'select',
      hooks: {
        onInit: (field: FormlyFieldConfig) => {
          form.get('sport').valueChanges.pipe(
+            takeUntil(this.onDestroy$),
            tap(sportId => ...),
          ).subscribe();
        },
      },
    },
  ];

+  ngOnDestroy(): void {
+    this.onDestroy$.next();
+    this.onDestroy$.complete();
+  }
}

The cascaded-select example has been cleaned in https://github.com/ngx-formly/ngx-formly/pull/1833 which doesn't rely on subscription.
well, I think I'm going to simplify that part https://github.com/ngx-formly/ngx-formly/issues/1986, so expect to be released in 5.7 version (
I'll let you know once done).

thanks for the quick reply...

Note: with v5.7.0 release, onInit can return and observables so the  subscription and unsubscribe is handled by Formly:
```patch
export class AppComponent implements OnDestroy {
-  onDestroy$ = new Subject<void>();
  ...
  fields: FormlyFieldConfig[] = [
    {
      key: 'select1',
      type: 'select',
      hooks: {
        onInit: (field: FormlyFieldConfig) => {
+          return form.get('sport').valueChanges.pipe(
-           takeUntil(this.onDestroy$),
            tap(sportId => ...),
+          );
-          ).subscribe();
        },
      },
    },
  ];

-  ngOnDestroy(): void {
-    this.onDestroy$.next();
-    this.onDestroy$.complete();
-  }
}

Note: with v5.7.0 release, onInit can return and observables so the subscription and unsubscribe is handled by Formly:
```patch
export class AppComponent implements OnDestroy {
-  onDestroy$ = new Subject<void>();
  ...
  fields: FormlyFieldConfig[] = [
    {
      key: 'select1',
      type: 'select',
      hooks: {
        onInit: (field: FormlyFieldConfig) => {
+          return form.get('sport').valueChanges.pipe(
-           takeUntil(this.onDestroy$),
            tap(sportId => ...),
+          );
-          ).subscribe();
        },
      },
    },
  ];

-  ngOnDestroy(): void {
-    this.onDestroy$.next();
-    this.onDestroy$.complete();
-  }
}

@aitboudad Hi, does that mean we don't have to manually complete our observables in the hooks methods?

does that mean we don't have to manually complete our observables in the hooks methods?

yes, but only for onInit hook


dependabot: Update docs jinja

Commit Message:  dependabot: Update docs jinja
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]

waiting on https://github.com/sphinx-doc/sphinx/issues/9216 - already resolved in sphinx main - just needs to be added to a release

/lgtm deps


Exclude build script by default

Closes #159

bors r+

Does this actually remove the build_script_build module from coverage results? By my (potentially-inaccurate) reading it looks like it just adds a flag that lets you opt in or out, but the logic for actually excluding those results hasn't changed. So it looks like if you opt out you just end up with the same behavior as what happened previously, no?

the logic for actually excluding those results hasn't changed

No. Changes to src/main.rs will change to ignore artifacts related to build scripts if --include-build-script flag is not passed.
if cx.cov.include_build_script {
    let dir = p.file_name().unwrap().to_string_lossy();
    if !cx.build_script_re.is_match(&dir) {
        return false;
    }
} else {
    // `false` means "ignore this path"
    return false;
}

If all corresponding artifacts are ignored, the file (and the module) will not be displayed in the report.

Published in 0.4.0.

I must have misunderstood the contents of the patch then. Thank you for the quick turnaround!

Confirmed that this works as expected now. Thanks again!


Add git fetch to base pullpost instructions

Added git fetch to instructions to quell the following error the contributor will otherwise encounter:
error: the requested upstream branch 'base/master' does not exist
hint:
hint: If you are planning on basing your work on an upstream
hint: branch that already exists at the remote, you may need to
hint: run "git fetch" to retrieve it.
...

There doesn't seem to be an appetite for this, so I'll close it to clean up the open PRs 👍


Could not build on Xcode 15

There is an issue with this
[(id)indicator setProgress:progress]
and shows a "Multiple methods named 'setProgress:' found with mismatched result, parameter type or attributes" error
This was from a manually imported library and not through pods
so I'm not quite sure how outdated this is.
- (void)updateUIForKeypath:(NSString *)keyPath {
	if ([keyPath isEqualToString:@"mode"] || [keyPath isEqualToString:@"customView"]) {
		[self updateIndicators];
	} else if ([keyPath isEqualToString:@"labelText"]) {
		label.text = self.labelText;
	} else if ([keyPath isEqualToString:@"labelFont"]) {
		label.font = self.labelFont;
	} else if ([keyPath isEqualToString:@"detailsLabelText"]) {
		detailsLabel.text = self.detailsLabelText;
	} else if ([keyPath isEqualToString:@"detailsLabelFont"]) {
		detailsLabel.font = self.detailsLabelFont;
	} else if ([keyPath isEqualToString:@"progress"]) {
		if ([indicator respondsToSelector:@selector(setProgress:)]) {
			[(id)indicator setProgress:progress];
		}
		return;
	}
	[self setNeedsLayout];
	[self setNeedsDisplay];
}

This problem can be solved using a special protocol that allows you to set progress.
Firstly, create the protocol MBProgressHUDProgressRepresentable in MBProgressHUD.h
@protocol MBProgressHUDProgressRepresentable <NSObject>
- (void)setProgress:(float)progress;
@end

Then, extend the MBRoundProgressView to conforms MBProgressHUDProgressRepresentable
/**
 * A progress view for showing definite progress by filling up a circle (pie chart).
 */
@interface MBRoundProgressView : UIView <MBProgressHUDProgressRepresentable>

Note: MBRoundProgressView already has implementation for setProgress: method
At the next step you need to forward MBProgressHUDProgressRepresentable just like MBProgressHUDDelegate
@protocol MBProgressHUDDelegate;
@protocol MBProgressHUDProgressRepresentable;  // <-- line to be added under @protocol MBProgressHUDDelegate;

And finaly replace this
if ([indicator respondsToSelector:@selector(setProgress:)]) {
	[(id)indicator setProgress:progress];
}

by this:
if ([indicator conformsToProtocol:@protocol(MBProgressHUDProgressRepresentable)]) {
	[(id<MBProgressHUDProgressRepresentable>)indicator setProgress: progress];
}

Note: if you are using customView as indicator you need to conform customView class to MBProgressHUDProgressRepresentable


Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-install-qispMG/tika/

Getting error while installing tika.
urllib2.HTTPError: HTTP Error 403: SSL is required

looks like an issue with your PIP installation that doesn't support SSL. Not a tika-python issue...


fix for public file export path

When exporting the public files directory the tar was being created with the path /var/www/drupal/web/sites/default/files, and then when that dump was imported, it would be placed back at that location and duplicate the path. This meant files are being placed at /var/www/drupal/web/sites/default/files/var/www/drupal/web/sites/default/files.
This PR changes the path inside the exported dump to be ./ which will allow us to extract the files wherever we want.
To reproduce the issue:

Install a fresh starter site with make starter
check the files directory with docker-compose exec drupal with-contenv bash -lc 'ls /var/www/drupal/web/sites/default/files'
make drupal-public-files-dump DEST=files.tgz
make drupal-public-files-import SRC=files.tgz
docker-compose exec drupal with-contenv bash -lc 'ls /var/www/drupal/web/sites/default/files' again
You should see that you now have your files duplicated at /var/www/drupal/web/sites/default/files/var/www/drupal/web/sites/default/files

To test this PR works:

add something to the files directory with docker-compose exec drupal with-contenv bash -lc 'touch /var/www/drupal/web/sites/default/files/test.txt'
docker-compose exec drupal with-contenv bash -lc 'ls /var/www/drupal/web/sites/default/files'
make drupal-public-files-dump DEST=files.tgz
remove the file with docker-compose exec drupal with-contenv bash -lc 'rm /var/www/drupal/web/sites/default/files/test.txt'
docker-compose exec drupal with-contenv bash -lc 'ls /var/www/drupal/web/sites/default/files'
make drupal-public-files-import SRC=files.tgz
docker-compose exec drupal with-contenv bash -lc 'ls /var/www/drupal/web/sites/default/files'
You should see that your file was added back to the correct location from the import

During committers call, decided we can fix this but need an option to use the old behaviour, in case people have workflows set up that rely on it working as it does now.

This should now let you specify the path. For the old behaviour, set the variable in your .env to PUBLIC_FILES_TAR_DUMP_PATH=/var/www/drupal/web/sites/default/files

Finally got to testing this, sorry for the delay. I followed the testing pr instructions and it works.


Add style guide link for Lint/ConstantDefinitionInBlock

Followup to https://github.com/rubocop-hq/rubocop/pull/8707, https://github.com/rubocop-hq/ruby-style-guide/pull/841.

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[ ] Added tests.
[x] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Run bundle exec rake default. It executes all tests and RuboCop for itself, and generates the documentation.

Thanks!


[FEATURE REQ] Make Spring Cloud Azure reference doc and MS Docs share the same content

Is your feature request related to a problem? Please describe.
Now we have two places for our docs, Spring Cloud Azure reference doc (https://microsoft.github.io/spring-cloud-azure) and MS Docs (https://docs.microsoft.com/en-us/azure/developer/java/spring-framework/). The ideal case for us is to combine only a copy of content, that is reference doc + getting started guides, and let them render on two sites.
Describe the solution you'd like
It's not easy for us to automate this process, but at first we can manually add the getting started guides as a chapter to the reference doc and create a PR to MS Docs to add the reference doc part.
Describe alternatives you've considered
Try to automate this process.
Additional context
N/A
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Description Added
[x] Expected solution specified

https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/2751

https://github.com/microsoft/spring-cloud-azure/pull/858

Closing this issue in favor of https://github.com/Azure/azure-sdk-for-java/issues/27570


KAFKA-2459: connection backoff, timeouts and retries

This fix applies to three JIRAs, since they are all connected.
KAFKA-2459Connection backoff/blackout period should start when a connection is disconnected, not when the connection attempt was initiated
Backoff when connection is disconnected
KAFKA-2615Poll() method is broken wrt time
Added Time through the NetworkClient API. Minimal change.
KAFKA-1843Metadata fetch/refresh in new producer should handle all node connection states gracefully
I’ve partially addressed this for a specific failure case in the JIRA.

Could we also add a unit test for leastLoadedNode's behavior? I think we don't test this at all currently. For this patch we could at least add a test that its new behavior for falling back on nodesEverSeen is correct, including that it respects blackout periods.

Thank you @ewencp . Added a unit test for leastLoadedNode that probes the blackout period

So I think to we'll treat this as closing KAFKA-2459. Despite partially addressing it, KAFKA-2615 we'll leave for the next patch which can add the Now interface (or whatever we end up calling it) -- I agree that separating that into another patch is better, especially since it's a far more extensive change. And again, this partially addresses KAFKA-1843, but that ticket is actually so far reaching that I think someone needs to break it down into more fine-grained tickets that can be tackled in smaller patches.
Make sense to everyone?

@enothereska Left one minor comment. Otherwise, LGTM. And I also agree with the plan to implement Now in a separate patch.

One minor comment, otherwise LGTM.

This fix applies to three JIRAs, since they are all connected.
KAFKA-2459Connection backoff/blackout period should start when a connection is disconnected, not when the connection attempt was initiated
Backoff when connection is disconnected
KAFKA-2615Poll() method is broken wrt time
Added Time through the NetworkClient API. Minimal change.
KAFKA-1843Metadata fetch/refresh in new producer should handle all node connection states gracefully
I’ve partially addressed this for a specific failure case in the JIRA.