text:
🛑 CEOTR Home Page loads is down

In 703a9be, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in e2a5e7a after 2 minutes.


text:
🛑 CEOTR Home Page loads is down

In e8e1a33, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in d98dc72 after 2 minutes.

source: gharchive/issue

repo: RKTowse/upptime

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 CEOTR Home Page loads is down

In 2fb88bd, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in 4a8fe7d after 2 minutes.


text:
🛑 CEOTR Home Page loads is down

In 9cb74eb, CEOTR Home Page loads (https://stg.ceotr.ca CEOTR Home) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CEOTR Home Page loads is back up in ecbedf9 after 2 minutes.


text:
🛑 RMUG CRM is down

In e2b4f3b, RMUG CRM (https://crm.rmusergroup.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RMUG CRM is back up in 23c52fe after 36 minutes.

repo: RM-User-Group/RMUG-Upptime


text:
Update hipLaunchCoopMultiKernel.cpp at the line 159

used reinterpret_cast<uint32_t*> for numBlocks, as expected by hipOccupancyMaxActiveBlocksPerMultiprocessor() api.

Can this be re-checked once, since in #1625 the API is modified to return the type int, the re-interpret cast might not be required.

source: gharchive/pull-request

repo: ROCm-Developer-Tools/HIP

license: mit

license_source: bigquery


text:
EXSWHTEC-217 - Implement new and update existing tests for the hipGraph*MemcpyNode family of APIs

Basic positive behavior tests
Negative parameter tests.

@mirza-halilcevic
Will you please resolve the merge conflicts for this PR?

PR has been merged into develop branch via commit cefbaed5cf253ff47d4df5a6c673395483615e25.

authors: mirza-halilcevic rakesroy rorake

repo: ROCm-Developer-Tools/hip-tests


text:
FP8 OCP to FP8 FNUZ on hardware with only FP8 FNUZ support

NANOO is short for NAN On Overflow, the data type comes from this paper: https://arxiv.org/pdf/2206.02915
Implements the method written about in #2717
This pass must run before simplify_qdq so that the adjusted scales and zero points are propagated to after the quantized operator.
The test in test/fp8_ocp_to_nanoo.cpp checks the pass works with simplify_qdq and does the expected operations
The test in test/ref/fp8_ocp_to_nanoo.cpp checks the pass produces the same result before and after
I will make a separate PR that removes the gpu context changes to get the gfx number
Fixed the cpp_generator that was using __builtin_nan incorrectly

Fixed the bug in the the pointwise compilation. __builtin_nan requires a string input that affects the most significant bits.

repo: ROCm/AMDMIGraphX


text:
Broken rocm link

On this page, https://github.com/ROCm-Developer-Tools/HIP/blob/master/INSTALL.md#hip-clang there is a broken link for rocm

@cpviolator Thanks! Sorry for the late response.  Internal ticket has been created to fix the broken link.

@cpviolator https://github.com/ROCm-Developer-Tools/HIP/blob/master/INSTALL.md#hip-clang is pointing to the documentation in the master branch which is a 3+ year old branch. It is not the default branch. The default branch is https://github.com/ROCm/HIP/tree/develop. Closing ticket. Thanks!

authors: cpviolator ppanchad-amd

repo: ROCm/HIP


text:
The Ubuntu 24.04 quick-start install instructions here simply don't work, yielding:

          The Ubuntu 24.04 quick-start install instructions [here](https://rocm.docs.amd.com/projects/install-on-linux/en/latest/install/quick-start.html) simply don't work, yielding:

The following packages have unmet dependencies:
 hipsolver : Depends: libcholmod3 but it is not installable
             Depends: libsuitesparseconfig5 but it is not installable
 rocm-gdb : Depends: libpython3.10 (>= 3.10.0) but it is not installable

I guess documentation was copied and pasted with only version number updates, assuming the steps would work about being tested.  No doubt testing these steps takes significant effort - but it's either once at source, or every poor user :-(
The detailed instructions here do work, I guess because it's vital to register the AMD repo's.
Originally posted by @chris-hatton in https://github.com/ROCm/ROCm/issues/2993#issuecomment-2480859340

Please correct the documentation

Hi @saadrahim, left a comment on the previous thread. I wasn't able to reproduce the dependency errors reported and it's likely the issue has to do with the user's environment. I've provided steps for a clean reinstallation
We can continue to use this thread for updates.

Was able to reproduce the exact dependency errors reported by the user. There was a mismatch in the amdgpu-install version on the system versus the OS installed (jammy amdgpu-install, noble OS installed). Will close out this issue as I've provided the exact steps to resolve this issue over at https://github.com/ROCm/ROCm/issues/2993#issuecomment-2498245912. Thanks!

authors: harkgill-amd saadrahim

repo: ROCm/ROCm


text:
SIGFPE (DIV/0) in ConvOclBwdWrW2::GetSolution()

Ubuntu 18.04
ROCm 2.0
VEGA56
python 3.6(conda) + ROCm TensorFlow 1.12
MIOpen-hip
When I run waveglow-tensorflow
https://github.com/b04901014/waveglow-tensorflow
Floating point exception(segmentation faulut) happens inside miopen::solver::ConvOclBwdWrW2::GetSolution for some reason.
How to reproduce
Setup hparams.py(e.g. edit path to LSJpeech) as described in waveglow-tensorflow's README.
Reduce wavnet_channels and wavenet_layers  to 256 and 7 respectively, since default configuration does not fit into VEGA's 8G GPU mem.
https://github.com/b04901014/waveglow-tensorflow/blob/master/src/hparams.py#L80
Then run python main.py.
I have disabled auto-tuning by setting TF_CUDNN_USE_AUTOTUNE=0, but this does not affect the issue: https://stackoverflow.com/questions/45063489/first-tf-session-run-performs-dramatically-different-from-later-runs-why
Following is the gdb trace.
Starting program: /home/syoyo/miniconda3/envs/py36/bin/python main.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff3933700 (LWP 15677)]
[New Thread 0x7ffff3132700 (LWP 15678)]
[New Thread 0x7fffee931700 (LWP 15679)]
[New Thread 0x7fffec130700 (LWP 15680)]
[New Thread 0x7fffe992f700 (LWP 15681)]
[New Thread 0x7fffe712e700 (LWP 15682)]
[New Thread 0x7fffe692d700 (LWP 15683)]
[New Thread 0x7fffe212c700 (LWP 15684)]
[New Thread 0x7fffe192b700 (LWP 15685)]
[New Thread 0x7fffdd12a700 (LWP 15686)]
[New Thread 0x7fffdc929700 (LWP 15687)]
[New Thread 0x7fffd8128700 (LWP 15688)]
[New Thread 0x7fffd5927700 (LWP 15689)]
[New Thread 0x7fffd3126700 (LWP 15690)]
[New Thread 0x7fffd2925700 (LWP 15691)]
[New Thread 0x7fffa9422700 (LWP 15694)]
[Thread 0x7fffd8128700 (LWP 15688) exited]
[Thread 0x7fffd2925700 (LWP 15691) exited]
[Thread 0x7fffd3126700 (LWP 15690) exited]
[Thread 0x7fffd5927700 (LWP 15689) exited]
[Thread 0x7fffdc929700 (LWP 15687) exited]
[Thread 0x7fffdd12a700 (LWP 15686) exited]
[Thread 0x7fffe192b700 (LWP 15685) exited]
[Thread 0x7fffe212c700 (LWP 15684) exited]
[Thread 0x7fffe692d700 (LWP 15683) exited]
[Thread 0x7fffe712e700 (LWP 15682) exited]
[Thread 0x7fffe992f700 (LWP 15681) exited]
[Thread 0x7fffec130700 (LWP 15680) exited]
[Thread 0x7fffee931700 (LWP 15679) exited]
[Thread 0x7ffff3132700 (LWP 15678) exited]
[Thread 0x7ffff3933700 (LWP 15677) exited]
WARNING:tensorflow:From /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/ops/distributions/distribution.py:265: ReparameterizationType.__init__ (from tensorflow.python.ops.distributions.distribution) is deprecated and will be removed after 2019-01-01.
Instructions for updating:
The TensorFlow Distributions library has moved to TensorFlow Probability (https://github.com/tensorflow/probability). You should update all references to use `tfp.distributions` instead of `tf.distributions`.
WARNING:tensorflow:From /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/ops/distributions/bernoulli.py:169: RegisterKL.__init__ (from tensorflow.python.ops.distributions.kullback_leibler) is deprecated and will be removed after 2019-01-01.
Instructions for updating:
The TensorFlow Distributions library has moved to TensorFlow Probability (https://github.com/tensorflow/probability). You should update all references to use `tfp.distributions` instead of `tf.distributions`.
[New Thread 0x7fffd2925700 (LWP 15700)]
Time Segments of audio for training: 16384
2019-01-10 21:01:47.951037: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: SSE4.1 SSE4.2 AVX AVX2 FMA
[New Thread 0x7fffd3126700 (LWP 15703)]
[New Thread 0x7fffd5927700 (LWP 15704)]
[New Thread 0x7fffd8128700 (LWP 15705)]
[New Thread 0x7fff8bf9e700 (LWP 15706)]
[New Thread 0x7fff8b79d700 (LWP 15707)]
[New Thread 0x7fff8af9c700 (LWP 15708)]
[New Thread 0x7fff8a79b700 (LWP 15709)]
[New Thread 0x7fff89f9a700 (LWP 15710)]
[New Thread 0x7fff89799700 (LWP 15711)]
[New Thread 0x7fff88f98700 (LWP 15712)]
[New Thread 0x7fff5bfff700 (LWP 15713)]
[New Thread 0x7fff5b7fe700 (LWP 15714)]
[New Thread 0x7fff53fff700 (LWP 15715)]
[New Thread 0x7fff5affd700 (LWP 15716)]
[New Thread 0x7fff5a7fc700 (LWP 15717)]
[New Thread 0x7fff59ffb700 (LWP 15718)]
[New Thread 0x7fff597fa700 (LWP 15719)]
2019-01-10 21:01:47.953664: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1530] Found device 0 with properties:
name: Vega [Radeon RX Vega]
AMDGPU ISA: gfx900
memoryClockRate (GHz) 1.59
pciBusID 0000:28:00.0
Total memory: 7.98GiB
Free memory: 7.73GiB
2019-01-10 21:01:47.953701: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1641] Adding visible gpu devices: 0
2019-01-10 21:01:47.953730: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1051] Device interconnect StreamExecutor with strength 1 edge matrix:
2019-01-10 21:01:47.953740: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1057]      0
2019-01-10 21:01:47.953749: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1070] 0:   N
2019-01-10 21:01:47.953799: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1189] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 7767 MB memory) -> physical GPU (device: 0, name: Vega [Radeon RX Vega], pci bus id: 0000:28:00.0)
[New Thread 0x7fff58ff9700 (LWP 15720)]
[New Thread 0x7fff537fe700 (LWP 15721)]
[New Thread 0x7fff52ffd700 (LWP 15722)]
[New Thread 0x7fff527fc700 (LWP 15723)]
[New Thread 0x7fff51ffb700 (LWP 15724)]
[New Thread 0x7fff517fa700 (LWP 15725)]
[New Thread 0x7fff50ff9700 (LWP 15726)]
[New Thread 0x7fff23fff700 (LWP 15727)]
[New Thread 0x7fff237fe700 (LWP 15728)]
[New Thread 0x7fff22ffd700 (LWP 15729)]
[New Thread 0x7fff227fc700 (LWP 15730)]
[New Thread 0x7fff21ffb700 (LWP 15731)]
[New Thread 0x7fff217fa700 (LWP 15732)]
[New Thread 0x7fff20ff9700 (LWP 15733)]
[New Thread 0x7ffefffff700 (LWP 15734)]
[New Thread 0x7ffeff7fe700 (LWP 15735)]
[New Thread 0x7ffefeffd700 (LWP 15736)]
[New Thread 0x7ffefe7fc700 (LWP 15737)]
Total number of parameters: 102664808
Total number of audio/text pair for training: 11790
Total number of audio/text pair for validation: 1310
Error Loading Model! Training From Initial State...
[New Thread 0x7ffeef53f700 (LWP 15751)]
[Thread 0x7ffeef53f700 (LWP 15751) exited]
[New Thread 0x7ffeef53f700 (LWP 15752)]
[Thread 0x7ffeef53f700 (LWP 15752) exited]
[New Thread 0x7ffeef53f700 (LWP 15753)]
[Thread 0x7ffeef53f700 (LWP 15753) exited]
[New Thread 0x7ffeef53f700 (LWP 15754)]
[Thread 0x7ffeef53f700 (LWP 15754) exited]
[New Thread 0x7ffeef53f700 (LWP 15755)]
[Thread 0x7ffeef53f700 (LWP 15755) exited]
Initialized
[New Thread 0x7ffeef53f700 (LWP 15756)]
Sampling to '../samples'
[New Thread 0x7ffed4d45700 (LWP 15831)]
  0%|                                                                                | 0/5 [00:00<?, ?it/s]Sampling to '../samples/Epoch_0-1.wav' ...
mels done
[New Thread 0x7ffecffff700 (LWP 15835)]
[Thread 0x7ffecffff700 (LWP 15835) exited]
[New Thread 0x7ffecffff700 (LWP 15836)]
[Thread 0x7ffecffff700 (LWP 15836) exited]
[New Thread 0x7ffecffff700 (LWP 15837)]
[Thread 0x7ffecffff700 (LWP 15837) exited]
[New Thread 0x7ffecffff700 (LWP 15838)]
[Thread 0x7ffecffff700 (LWP 15838) exited]
out done
write wav done
 20%|█████████████████████▏                                                                                | 1/5 [00:38<02:32, 38.14s/it]Sampling to '../samples/Epoch_0-2.wav' ...
mels done
out done
write wav done
 40%|██████████████████████████████████████████▍                                                               | 2/5 [01:00<01:40, 33.51s/it]Sampling to '../samples/Epoch_0-3.wav' ...
mels done
out done
write wav done
 60%|███████████████████████████████████████████████████████████████▌                                          | 3/5 [01:31<01:05, 32.80s/it]Sampling to '../samples/Epoch_0-4.wav' ...
mels done
out done
write wav done
 80%|████████████████████████████████████████████████████████████████████████████████████▊                     | 4/5 [01:59<00:31, 31.23s/it]Sampling to '../samples/Epoch_0-5.wav' ...
mels done
out done
write wav done
100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████| 5/5 [02:26<00:00, 29.85s/it]
[New Thread 0x7ffecffff700 (LWP 18163)]
[Thread 0x7ffecffff700 (LWP 18163) exited]
[New Thread 0x7ffecffff700 (LWP 18164)]
[Thread 0x7ffecffff700 (LWP 18164) exited]
[New Thread 0x7ffecffff700 (LWP 18165)]
[Thread 0x7ffecffff700 (LWP 18165) exited]
Current learning rate: 1.000000e-04
[New Thread 0x7ffecffff700 (LWP 18166)]
  0%|                                                                                | 0/2947 [00:00<?, ?it/s]dequeing...
dequeued.
2019-01-10 21:04:56.901119: W ./tensorflow/core/grappler/optimizers/graph_optimizer_stage.h:237] Failed to run optimizer ArithmeticOptimizer, stage HoistCommonFactor. Error: Node ArithmeticOptimizer/HoistCommonFactor_Add_add_24 is missing output properties at position :0 (num_outputs=0)
[Thread 0x7ffed4d45700 (LWP 15831) exited]
[New Thread 0x7ffed4d45700 (LWP 18167)]
[Thread 0x7ffed4d45700 (LWP 18167) exited]
[New Thread 0x7ffed4d45700 (LWP 18168)]
[Thread 0x7ffed4d45700 (LWP 18168) exited]
[New Thread 0x7ffed4d45700 (LWP 18169)]
[Thread 0x7ffed4d45700 (LWP 18169) exited]
[New Thread 0x7ffed4d45700 (LWP 18170)]
[Thread 0x7ffed4d45700 (LWP 18170) exited]

Thread 46 "python" received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7fff227fc700 (LWP 15730)]
0x00007fffb4cb329d in miopen::solver::ConvOclBwdWrW2::GetSolution(miopen::ConvolutionContext const&) const ()
   from /opt/rocm/lib/libMIOpen.so.1
(gdb) bt
#0  0x00007fffb4cb329d in miopen::solver::ConvOclBwdWrW2::GetSolution(miopen::ConvolutionContext const&) const ()
   from /opt/rocm/lib/libMIOpen.so.1
#1  0x00007fffb4cb1157 in miopen::solver::ConvOclBwdWrW2::IsApplicable(miopen::ConvolutionContext const&) const ()
   from /opt/rocm/lib/libMIOpen.so.1
#2  0x00007fffb4d6393e in std::vector<miopen::solver::ConvSolution, std::allocator<miopen::solver::ConvSolution> > miopen::solver::SearchForAllSolutions<miopen::solver::ConvAsmBwdWrW1x1, miopen::solver::ConvAsmBwdWrW3x3, miopen::solver::ConvOclBwdWrW2, miopen::solver::ConvOclBwdWrW53, miopen::solver::ConvOclBwdWrW1x1, miopen::ConvolutionContext, miopen::MultiFileDb, miopen::solver::ConvSolution>(miopen::ConvolutionContext const&, miopen::MultiFileDb)::{lambda(auto:1)#1}::operator()<miopen::solver::ConvOclBwdWrW2> () from /opt/rocm/lib/libMIOpen.so.1
#3  0x00007fffb4d447c0 in std::vector<miopen::solver::ConvSolution, std::allocator<miopen::solver::ConvSolution> > miopen::solver::SearchForAllSolutions<miopen::solver::ConvAsmBwdWrW1x1, miopen::solver::ConvAsmBwdWrW3x3, miopen::solver::ConvOclBwdWrW2, miopen::solver::ConvOclBwdWrW53, miopen::solver::ConvOclBwdWrW1x1, miopen::ConvolutionContext, miopen::MultiFileDb, miopen::solver::ConvSolution>(miopen::ConvolutionContext const&, miopen::MultiFileDb) () from /opt/rocm/lib/libMIOpen.so.1
#4  0x00007fffb4d446b8 in mlo_construct_BwdWrW2D::FindAllSolutions() () from /opt/rocm/lib/libMIOpen.so.1
#5  0x00007fffb4b60da5 in miopen::ConvolutionDescriptor::BackwardWeightsGetWorkSpaceSizeDirect(miopen::Handle&, miopen::TensorDescriptor const&, miopen::TensorDescriptor const&, miopen::TensorDescriptor const&) const () from /opt/rocm/lib/libMIOpen.so.1
#6  0x00007fffb4b6153d in miopen::ConvolutionDescriptor::ConvolutionBackwardWeightsGetWorkSpaceSize(miopen::Handle&, miopen::TensorDescriptor const&, miopen::TensorDescriptor const&, miopen::TensorDescriptor const&) const () from /opt/rocm/lib/libMIOpen.so.1
#7  0x00007fffb4b6c992 in miopenConvolutionBackwardWeightsGetWorkSpaceSize () from /opt/rocm/lib/libMIOpen.so.1
#8  0x00007fffc184ac24 in bool stream_executor::rocm::MIOpenSupport::DoConvolveBackwardFilterImpl<float>(stream_executor::Stream*, int, stream_executor::dnn::BatchDescriptor const&, stream_executor::DeviceMemory<float> const&, stream_executor::dnn::BatchDescriptor const&, stream_executor::DeviceMemory<float>, stream_executor::dnn::ConvolutionDescriptor const&, stream_executor::dnn::FilterDescriptor const&, stream_executor::DeviceMemory<float>*, stream_executor::ScratchAllocator*, stream_executor::dnn::AlgorithmConfig const&, stream_executor::dnn::ProfileResult*) () from /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#9  0x00007fffc184b1b5 in stream_executor::rocm::MIOpenSupport::DoConvolveBackwardFilter(stream_executor::Stream*, stream_executor::dnn::BatchDescriptor const&, stream_executor::DeviceMemory<float> const&, stream_executor::dnn::BatchDescriptor const&, stream_executor::DeviceMemory<float>, stream_executor::dnn::ConvolutionDescriptor const&, stream_executor::dnn::FilterDescriptor const&, stream_executor::DeviceMemory<float>*, stream_executor::ScratchAllocator*, stream_executor::dnn::AlgorithmConfig const&, stream_executor::dnn::ProfileResult*) ()
   from /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#10 0x00007fffb9813309 in stream_executor::Stream::ThenConvolveBackwardFilterWithAlgorithm(stream_executor::dnn::BatchDescriptor const&, stream_executor::DeviceMemory<float> const&, stream_executor::dnn::BatchDescriptor const&, stream_executor::DeviceMemory<float>, stream_executor::dnn::ConvolutionDescriptor const&, stream_executor::dnn::FilterDescriptor const&, stream_executor::DeviceMemory<float>*, stream_executor::ScratchAllocator*, stream_executor::dnn::AlgorithmConfig const&, stream_executor::dnn::ProfileResult*) ()
   from /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/../libtensorflow_framework.so
#11 0x00007fffc1030c5d in tensorflow::LaunchConv2DBackpropFilterOp<Eigen::GpuDevice, float>::operator()(tensorflow::OpKernelContext*, bool, bool, tensorflow::Tensor const&, tensorflow::Tensor const&, int, int, int, int, tensorflow::Padding const&, tensorflow::Tensor*, tensorflow::TensorFormat) () from /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#12 0x00007fffc103197d in tensorflow::Conv2DSlowBackpropFilterOp<Eigen::GpuDevice, float>::Compute(tensorflow::OpKernelContext*) ()
   from /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so
#13 0x00007fffb9416df1 in tensorflow::BaseGPUDevice::ComputeHelper(tensorflow::OpKernel*, tensorflow::OpKernelContext*) ()
---Type <return> to continue, or q <return> to quit---
   from /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/../libtensorflow_framework.so
#14 0x00007fffb9417319 in tensorflow::BaseGPUDevice::Compute(tensorflow::OpKernel*, tensorflow::OpKernelContext*) ()
   from /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/../libtensorflow_framework.so
#15 0x00007fffb94600b3 in tensorflow::(anonymous namespace)::ExecutorState::Process(tensorflow::(anonymous namespace)::ExecutorState::TaggedNode, long long) () from /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/../libtensorflow_framework.so
#16 0x00007fffb946027f in std::_Function_handler<void (), tensorflow::(anonymous namespace)::ExecutorState::ScheduleReady(absl::InlinedVector<tensorflow::(anonymous namespace)::ExecutorState::TaggedNode, 8ul, std::allocator<tensorflow::(anonymous namespace)::ExecutorState::TaggedNode> > const&, tensorflow::(anonymous namespace)::ExecutorState::TaggedNodeReadyQueue*)::{lambda()#1}>::_M_invoke(std::_Any_data const&) ()
   from /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/../libtensorflow_framework.so
#17 0x00007fffb95137a1 in Eigen::NonBlockingThreadPoolTempl<tensorflow::thread::EigenEnvironment>::WorkerLoop(int) ()
   from /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/../libtensorflow_framework.so
#18 0x00007fffb95112c6 in std::_Function_handler<void (), tensorflow::thread::EigenEnvironment::CreateThread(std::function<void ()>)::{lambda()#1}>::_M_invoke(std::_Any_data const&) ()
   from /home/syoyo/miniconda3/envs/py36/lib/python3.6/site-packages/tensorflow/python/../libtensorflow_framework.so
#19 0x00007fffb4a57678 in std::execute_native_thread_routine_compat (__p=<optimized out>)
    at /opt/conda/conda-bld/compilers_linux-64_1534514838838/work/.build/x86_64-conda_cos6-linux-gnu/src/gcc/libstdc++-v3/src/c++11/thread.cc:94
#20 0x00007ffff7bbd6db in start_thread (arg=0x7fff227fc700) at pthread_create.c:463
#21 0x00007ffff78e688f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Fix has been included in 1.7.1: https://github.com/ROCmSoftwarePlatform/MIOpen/commit/a478ac8d5d3896e910721832379c16ea5ced06bc

repo: ROCmSoftwarePlatform/MIOpen


text:
"Memory access fault by GPU node-1" error in Conv3d.

🐛 Bug
Got "Memory access fault by GPU node-1" when training my model, now I can reproduce the problem in a very simple script.
the env is ROCM 2.9.6, Radeon VII, I compiled pytorch from the most recent source on master branch.
details as follow.
To Reproduce
import torch
import torch.nn as nn
t=torch.rand(2,32,64,128,160).to('cuda')
t2=nn.Conv3d(32, 16, kernel_size=3, stride=1, padding=1, bias=False).to('cuda')(t) #error occurs.
Python 3.7.5 (default, Oct 25 2019, 15:51:11)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.

import torch
import torch.nn as nn
t=torch.rand(2,32,64,128,160).to('cuda')
HIP_DB=0x1 [api]
hip-api pid:9748 tid:1:HIP initialized short_tid#1 (maps to full_tid: 0x7fba8044f740)
t2=nn.Conv3d(32, 16, kernel_size=3, stride=1, padding=1, bias=False).to('cuda')(t)
<<hip-api pid:9748 tid:1.63 9748 1.63 hipLaunchKernel 'ZN12_GLOBAL__N_110hip_fill_nILj256EPjmjEEvT0_T1_T2' gridDim:{163840,1,1} groupDim:{256,1,1} sharedMem:+0 stream:0.0 @5334006293209
<<hip-api pid:9748 tid:1.69 9748 1.69 hipLaunchKernel 'ZN2at6native14vol2col_kernelIfEEviPKT_iiiiiiiiiiiiiiiiiiPS2' gridDim:{40960,1,1} groupDim:{1024,1,1} sharedMem:+0 stream:0.0 @5340563243577
<<hip-api pid:9748 tid:1.409 9748 1.409 hipLaunchKernel 'Cijk_Ailk_Bljk_SB_MT128x64x8_SE_APM1_AF0EM1_AF1EM1_AMAS3_ASEM1_BL1_DTL0_EPS1_FL1_GRVW4_GSU1_ISA906_IU1_K1_KLA_LPA0_LPB0_LDL1_MGWVW1_NLCA1_NLCB1_PK0_PGR1_PLR1_RK0_SU32_SNLL0_TT8_4_USFGRO0_VAW1_VW4_WG16_16_1_WGM8' gridDim:{10240,1,1} groupDim:{256,1,1} sharedMem:+0 stream:0.0 @5340572207622
Memory access fault by GPU node-1 (Agent handle: 0x55e2fa08a6f0) on address 0x7fb968e02000. Reason: Page not present or supervisor privilege.
Aborted (core dumped)

Environment
ROCM Version: 2.9.6
PyTorch version: 1.4.0a0+21ab112
Is debug build: No
CUDA used to build PyTorch: Could not collect
OS: Ubuntu 18.04.3 LTS
GCC version: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
CMake version: version 3.12.0
Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 10.0.130
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
Versions of relevant libraries:
[pip] numpy==1.17.3
[pip] torch==1.4.0a0+21ab112
[pip] torchvision==0.2.0
[conda] mkl                       2019.4                      243
[conda] mkl-include               2019.4                      243

any progress on this issue? @daniellowell @amcamd

Is there any trick to get around this issue? for example, can I switch to anther backend for conv3d?

problem still exist on ROCM 2.10.

is there someone following up? I encounter this error, too. is it a bug?

yes, I have send back my Radeon VII to seller and have swatched to RTX 2070 because this problem.

authors: dodatko singvision sugar-mouse

repo: ROCmSoftwarePlatform/Tensile


text:
__sincosf issue in rocrand_normal

https://github.com/ROCmSoftwarePlatform/rocRAND/blob/master/library/include/rocrand_normal.h#L54
With recent changes to HIP, __sincosf is getting mapped to native device implementations for speed advantage at the expense of no precision guarantees; does rocrand provide mechanism to choose between fast vs accurate (example __sincosf vs sincosf) so user has some control? We are seeing accuracy issues due to this, and looking for recommendations

Question about how to know which functions are future-proof.
So the old sincosf is removed, the current __sincosf moves sincosf, and a new native implementation is put for __sincosf?
I understood more functions are being made native, but these seem to get _native in the function name. How is decided when a new function is added like __ocml_cos_f32 - > __ocml_native_cos_f32 and when is it like here? Is this because OCML functions always have to start with __? Now I'm not sure if a function starting with __ can potentially be made less accurate in the future. Could you explain? Should we add unit-tests to check for accuracy? Is there a planning document of native functions that are targeted with some info on performance and accuracy?

I have been thinking of OCML as a language internal implementation library without a fully stable API (hence the __ prefix). I did a cleanup a while ago since there was a naming inconsistency mess with some of the builtins, so now the native ones should be equivalent to the OpenCL versions, but IIRC there wasn't actually a change in behavior. Not sure what's going on in HIP. Public API functions definitely should not start with __.

OCML is an internal library to be used by language runtimes so I think we should take it out of this discussion.  What should be talking about here are the differences between HIP/Cuda  __function vs function, e.g. __sincosf vs. sincosf.  Those differences are documented, at least in the Cuda documentation, and it says that the accuracy provided by the __ variants is lower and the domain may be reduced, to permit faster execution.  Our first implementation of the __ variants did not provide better performance (and reduced accuracy) but we have corrected that.  I can certainly see how this could have misled developers in the past, but in general developers should be prepared to regularly test the __ variants as their accuracy can change from release to release and from device to device.

Ok, I follow how OCML is positioned here. Thanks Matt.
My experience with __ functions is that they are always faster, but sometimes less accurate and sometimes only i.e. not IEEE-compliant like denorms.
Not sure if we can take that responsibility, as we'll probably find out by accident if such change arrives. This means a bug could get in without us knowing, or that a potential performance upgrade could be left out without knowing. Could the HIP-team therefore start profiding a CHANGELOG.md that includes this kinds of changes? Please?

authors: VincentSC arsenm b-sumner bragadeesh

repo: ROCmSoftwarePlatform/rocRAND


text:
BooruBridge similar to WordPressBridge?

There are a lot of bridges that extend basically from BooruprojectBridge or DanbooruBridge:

DollbooruBridge
GelbooruBridge
KonachanBridge
LolibooruBridge
MilbooruBridge
MspabooruBridge
Rule34Bridge
Rule34pahealBridge
SafebooruBridge
SakugabooruBridge
Shimmie2Bridge
TbibBridge
XbooruBridge
YandereBridge

Most bridges overwrite some constants and don't add any additional functions, so maybe it is possible to do something similar to WordPressBridge where you can insert the URL and request data for any compatible site. I'm not (yet) familiar with the site contents, but is "booru" something similar to WordPress which we can utilize with a more general approach?

I'm not (yet) familiar with the site contents,

don't bother, it's nasty: I burned my eyes doing the refactoring of the .*ooru.* bridges :)
I really don't like the fact that a full url can be used as a parameter: to many things could go wrong if the right verifications are not done, the first of them being the RSS-bridge host used as a proxy for whatever purpose.
I was rather going in the opposite direction where WordPressBridge it self should be used only for websites hosted by wordpress.com (example.wordpress.com), and use children of WordPressBridge to bridge sites powered by wordpress on any other host

I'll take your comment from #401 here, so we can have one common platform:

I was rather going in the opposite direction where WordPressBridge it self should be used only for websites hosted by wordpress.com (example.wordpress.com), and use children of WordPressBridge to bridge sites powered by wordpress on any other host

I really don't like the fact that a full url can be used as a parameter: to many things could go wrong if the right verifications are not done, the first of them being the RSS-bridge host used as a proxy for whatever purpose.

There are probably hundreds of thousands of WordPress sites out there, so the possible amount of bridges that can be implemented is just impossible to maintain. This is why in the past a whole bunch of compatible WordPress bridges were removed with the strict requirement to use the general WordPress bridge instead. An array of supported URLs however is a different matter and only requires the change of one single line in order to add/remove another site.
So in order to limit the input to a given set of values we just need a drop-down list.

I have an upcoming patch that will add information about HTTPS status of each sites : even if they share the same content structure, their HTTPS status can be very different, which means that bridges can access data over a secure connection for some while using an insecure connection for others

So, for as long as we can paste custom URLs, it would be possible to request HTTP for a site that actually supports HTTPS, right?
A drop-down list will limit the input to specific sites and can also enforce secure connections. Additionally, by using the two-layer approach (sub-elements), we can even add additional pages for each site (for specific forums and such).

don't bother, it's nasty: I burned my eyes doing the refactoring of the .ooru. bridges :)

:disappointed:

So in order to limit the input to a given set of values we just need a drop-down list.

Except that users may not be aware of the  undergoing CMS used by the site they want to see supported, therefore they will not go check in the WhateverBridge drop-down list.
The current way of listing bridges according to the site they are related to should be conserved.
I imagine a more generic way :

Bridge 'ParentBridge' used as a base for other sites would have these sites in a directory 'bridges/Parent/'.
In this directory would be

one special file containing an associative array which stores all the websites and their specificities, as long as these do not require to modify the content scraped by the parent bridge, such as the HTTPS status.
any children bridges that would require more adaptation to the scraping process or to already scraped website content, such as specific content filtering for WordPressBridge children.

the bridges listing code would be modified to recursively search in these 'bridges/Parent/' subdirectories to

generate virtual bridges for the websites stored in the special file
add the children bridges to the listing

Consider the above as pulled out of my head without any real strong thinking about its feasibility or bad consequences.

the first of them being the RSS-bridge host used as a proxy for whatever purpose.

Yes @pmaziere it was actually the purpose for Xbooru, initially ^^ http://www.numerama.com/magazine/33328-des-sites-de-mangas-hentai-bloques-en-france.html Some year ago I used booru bridges in combination with Autoblogs.
While boorus have the same principles, several CMS exist. Booruproject being a platform like Wordpress.com, there's also Danbooru, Gelbooru, and the more evolved Moebooru (used by Konachan, Yande.re,..) it's PHP fork MyImouto (Lolibooru), Shimmie (Milbooru)...
Trying to pinpoint recurring elements to use in unified bridge could be tough, but could really help reducing the number of different bridges (and allowing easier addition of more supported websites)

Yes @pmaziere it was actually the purpose for Xbooru, initially ^^ http://www.numerama.com/magazine/33328-des-sites-de-mangas-hentai-bloques-en-france.html Some year ago I used booru bridges in combination with Autoblogs.

That's not what I'm talking about: I meant using any flaw in the url processing code (or lack of processing, such as what was done in the VkBridge) to download whatever data from the RSS-Bridge provider host, unrelated to the initial RSS-Bridge goal.

Trying to pinpoint recurring elements to use in unified bridge could be tough, but could really help reducing the number of different bridges (and allowing easier addition of more supported websites)

that's what have been done in cd361f8fc035de8ed5561bfd1e887e1046808e04

Except that users may not be aware of the undergoing CMS used by the site they want to see supported, therefore they will not go check in the WhateverBridge drop-down list.

So, we need a better way to guide the users to the correct bridge. This is a usability issue, not a bridge issue.

The current way of listing bridges according to the site they are related to should be conserved.

We can do the same by adding more information to existing bridges. Imagine something like this:
class CMSBridge extends BridgeAbstract {
	// We don't need this anymore (because of SITES)
	//
	// const NAME = "CMS Bridge";
	// const URI = "https://cms.com";
	// const DESCRITPION = "A bridge to cover sites generated by CMS";

	const PARAMETERS = array(
		"u" => array(
			"name" => "username",
			"required" => true
		)
	);

	const SITES = array(
		"site1" => array(
			"name" => "MySite",
			"uri" => "https://my-site.com",
			"description" => "Returns the latest news from 'MySite'"
		),
		"site2" => array(
			"name" => "Other site",
			"uri" => "https://other-site.com",
			"description" => "Returns the latest new from 'other-site.com'"
		)
	);

// And so on, and so forth...

}

We can render this into multiple cards, where each card uses the exact same PARAMETERS and collectData implementation. Of course for sites that require additional functions we can either create a new bridge or do optional stuff based on the current site.
The whitelist can then either apply to the entire CMSBridge, or just a few SITES within the bridge (like "site1" could be whitelisted like "CMSBridge_site1" or something similar.

I also imagine a more generic way of actually displaying bridges:
Right now we got about 120 bridges, which are rendered into a very long page. This is a very inefficient way of doing things and in my opinion already exceeded the point of being user-unfriendly. Adding more bridges/cards will just make things worse.
Instead of displaying all bridges on one page, we should rather provide a simple list of domain names (with some kind of search filter), so the user can select or search the site of their choice. Next the user can choose options and select the output format like they can do now.

We can do the same by adding more information to existing bridges. Imagine something like this:
[snip code]

For something like WordPressBridge, it's going to be a huge const SITES array.
I'd rather see those constants stored in a separate file, in a format designed to store data like JSON, than in a php class since this class will never use those data. They will only be used by the HTMLUtils:displayBridgeCard() method to create the cards corresponding to these virtual bridges.

Instead of displaying all bridges on one page, we should rather provide a simple list of domain names (with some kind of search filter), so the user can select or search the site of their choice. Next the user can choose options and select the output format like they can do now.

do you mean something like an alphabetic index and a search box ?

I'd rather see those constants stored in a separate file, in a format designed to store data like JSON, than in a php class since this class will never use those data. They will only be used by the HTMLUtils:displayBridgeCard() method to create the cards corresponding to these virtual bridges.

That would be the preferred solution. :+1:
Just, how do we get URI and NAME to the bridge for actual data collection?
I just pushed a sandbox branch on my fork to attempt what I wrote earlier: https://github.com/LogMANOriginal/rss-bridge/tree/MultiSiteBridges
That branch only has the WordPress bridge working with three sites. I tested everything except caching and whitelisting and it is most certainly possible. Still, changing all bridges to use the SITES constant (or a JSON file for that matter) is no good solution, but using another base class for CMS based bridges sounds like a good alternative.

do you mean something like an alphabetic index and a search box ?

Yes, exactly.

Still, changing all bridges to use the SITES constant (or a JSON file for that matter) is no good solution, but using another base class for CMS based bridges sounds like a good alternative.

I agree.
As a prerequirement, here are the tasks I think should be done:

Bridge::create() should be a static method belonging to BridgeAbstract class
Refactorize Bridge and  Cache classes, and rename Bridge to BridgeList
Rename BridgeAbstract to Bridge
Methods that use current class constants would use the constants by default, but would also have the possibility to receive this data through an argument. i.e:

Bridge::setInputs(array $inputs, $queriedContext)

becomes
Bridge::setInputs(array $inputs, $queriedContext, $parameters=static::PARAMETERS)

Then we could reorganize the class hierarchy as follows:
Bridge
  => MultiBridge where:

JSON handling methods are implemented
class constants usage is overridden
by default, display of the children bridges is forbidden, since only virtual bridges should be allowed

    => FeedExpander where JSON should define a feed URI in addition to the site URI
      => WordPressBridge
    => *ooru stuff
as you did in your branch with the SITES constant, JSON file defines

the name of a virtual bridge as a key for each specific site data
required data: description, site URI
any other optional data that could be handled by the MultiBridge children such as feed URI for FeedExpander, which would be ignored by WordPressBridge since it builds it from the site URI.

And the alphabetical index can be implemented and the search box  could be implemented independently from the above.
I'll put the HTTPS status feature I implemented on hold since it would need to be adapted to all the above changes

These are some quite heavy changes. You raise some really interesting points that got me thinking for a couple of hours. Finally I got an idea that might be easier to implement with less refactoring (sorry in advanced for the long comment :sweat_smile:):
First of all, right now BridgeAbstract contains a lot of functions which really should not be part of it. The purpose of BridgeAbstract is to provide a base class that covers standard implementations for all functions defined in the interface.
So we should place following functions into separate and maybe already existing classes:

Error handling and debugging functions:

returnError
returnClientError
returnServerError
debugMessage

Data collection functions:

getContents
getSimpleHTMLDOM
getSimpleHTMLDOMCached

Functions related to input validation:

validateTextValue
validateNumberValue
validateCheckboxValue
validateListValue
validateData
getQueriedContext

Bridge::create() should be a static method belonging to BridgeAbstract class

I have thought about it and came to one important conclusion: The purpose of BridgeAbstract is to be a base class for all bridges and it is not supposed to be a factory for bridges. Which brings me to the next point: We need a bridge factory class.
Right now we build bridge cards based on the files on disk. This is a very simple solution which now hit its limits. What we need is a factory class that builds bridges based on regular bridge classes AND based on JSON-formatted data with some base class.
In order to do that we have to provide some kind of indicator in order to distinguish between "normal" bridges and "multi" bridges. At the same time both types should still be able to make use of all standard functions in BridgeAbstract. One of the easiest ways to do that, is to introduce another interface for "multi" bridges. Let's call it "MultiBridge" for now:
interface MultiBridge {}

The interface does not necessarily need to define any functions (though I think it will). However, using that additional interface we are already able to distinguish bridges by using something like if($class instanceof MultiBridge){...} else {...}! (this is only an example, there is a more cleaner way...) That way we can build bridges and do whitelisting and similar stuff easily (use ::NAME, ::URI, etc.. for regular bridges, load JSON-file for "multi" bridges).
Of course there are many more details to work out, but I think this way we are very flexible and could even introduce additional bridge variations in the future.

I'll put the HTTPS status feature I implemented on hold since it would need to be adapted to all the above changes

By using the interface approach it shouldn't be a problem to continue your project, since existing bridges wouldn't be touched in any destructive way. Actually I'm pretty sure we only need to change very little of the existing code and can focus on new functions entirely... probably™ :stuck_out_tongue_winking_eye:

I hope I was able to convey my idea. At the weekend I should be able to write some code examples based on the real code.
On a side note: I think it makes sense to have TWO interfaces and actually define the const::NAME, const::URI, etc... in the interface in order to make things more specific. (We can actually have another layer between BridgeAbstract and the bridges in order to get base classes for MultiBridge and RegularBridge and thus have more intelligent getName, getURI, etc... functions.)

Error handling and debugging functions:
returnError
returnClientError
returnServerError
debugMessage
Data collection functions:
getContents
getSimpleHTMLDOM
getSimpleHTMLDOMCached

From my point of view, these do not justify to be methods of a class: simple functions should be sufficient, but I may have missed something.

Functions related to input validation:
validateTextValue
validateNumberValue
validateCheckboxValue
validateListValue
validateData
getQueriedContext

Input validation methods are related to the bridge parameters and won't be used elsewhere, so I fail to see what could justify their removal from BridgeAbstract ?
I may need more explanations to understand your two interface solution: I don't see how multiple interfaces would be more appropriate than a simple class hierarchy.  An interface defines elements that a class must implement to be considered valid. If different classes with no hierarchical relationship shares these elements, then the interface is justified, but when the classes can be represented as a hierarchy, where is the need for this interface ?
Note that I consider this remark as valid for the current way of using BridgeInterface: I don"t understand its requirement compared to abstract methods directly declared in the BridgeAbstract class.
Again did I fail to see the benefits of interfaces in this case ?

From my point of view, these do not justify to be methods of a class: simple functions should be sufficient

:+1:

Input validation methods are related to the bridge parameters and won't be used elsewhere, so I fail to see what could justify their removal from BridgeAbstract ?

A bridge should do input validation, but it should not implement the actual code for doing so. Right now a bridge overriding validateNumberValue would be absolutely correct, but in reality we don't want that.

I don't see how multiple interfaces would be more appropriate than a simple class hierarchy.

It's not more or less appropriate, just a different solution I think is easier to implement, also because it has absolutely no impact on existing bridges. Both solutions should be equally fine in the long run.

An interface defines elements that a class must implement to be considered valid. If different classes with no hierarchical relationship shares these elements, then the interface is justified, but when the classes can be represented as a hierarchy, where is the need for this interface ?

I'll try to explain how I think about it:

Bridges and MultiBridges are like Cars and Trucks (talking about objects). They are on the same level of the hierarchy and only share a common parent (BridgeAbstract respectively BridgeInterface, or Vehicle). However there are distinct differences between them, which are not covered by the common base.
Bridge provides NAME, URI, DESCRIPTION by design and the BridgeInterface already defines functions to access them via getName, getURI and getDescription. MultiBridge on the other hand does not know NAME, URI or DESCRIPTION, but instead requires us to tell it these parameters based on the JSON-formatted file on disk. To close the circle, Bridge cannot work with any additional parameters received from a JSON-formatted file.
This is where another interface comes into play: MultiBridge will still adhere to the BridgeInterface, but it will also adhere to the additional MultiBridgeInterface which requires MultiBridge to implement additional functions for the caller to be able to set the additional data.
There is one very important factor here: MultiBridge is not responsible for loading data from disk. This is done by the caller.

Note that I consider this remark as valid for the current way of using BridgeInterface: I don"t understand its requirement compared to abstract methods directly declared in the BridgeAbstract class.
Again did I fail to see the benefits of interfaces in this case ?

There are many ways to do the same thing. An interface just defines functions, where an abstract class can already implement a certain set of functions. Interfaces however clearly state how the "contract" between the caller and callee works, without any distraction of implementation, where abstract classes are much harder to comprehend. For our small classes this is not a very big factor, but you can see the impact for very complex interfaces.

I have pushed a new branch on my fork to show a possible interface solution: https://github.com/LogMANOriginal/rss-bridge/tree/InterfaceMultiBridge
Again, this is far from being final, but it already does work with the three sites for WordPressBridge. All existing bridges are still working as before btw.
Please notice that HTMLUtils is very messy as I just duplicated the original code with some adjustments for MultiBridges. This can be done in a much more cleaner way by using functions.

Bridges and MultiBridges are like Cars and Trucks (talking about objects). They are on the same level of the hierarchy and only share a common parent (BridgeAbstract respectively BridgeInterface, or Vehicle). However there are distinct differences between them, which are not covered by the common base.

That's where we diverge: I consider the MultiBridge class to be a child of the misnamed BridgeAbstract.
The BridgeAbstract class is the base class for all bridges (hence should be renamed Bridge) and the MultiBridge class is derived form the BridgeAbstract class since, in addition to other derivated bridge classes that requires an actual new class,  it can also be used as a base for other virtual bridges whose data can be found in the JSON file.
ie: WordPressBridge classi, that would derive from MultiBridge class, could be used to bridge any sites from *.wordpress.com, while the JSON file it is associated with would define the data that allow access to other domains.

Bridge provides NAME, URI, DESCRIPTION by design and the BridgeInterface already defines functions to access them via getName, getURI and getDescription. MultiBridge on the other hand does not know NAME, URI or DESCRIPTION, but instead requires us to tell it these parameters based on the JSON-formatted file on disk. To close the circle, Bridge cannot work with any additional parameters received from a JSON-formatted file.

So you don't consider a MultiBridge class at all, but rather another interface implemented by existing bridges, while I consider a new MultiBridge class derived from Bridge Abstract from which existing bridges like WordPressBridge could derive.

There is one very important factor here: MultiBridge is not responsible for loading data from disk. This is done by the caller.

I fail to understand the benefit of the above.
In your implementation you will have to replicate the setSite method in each bridges implementing the MultiBridge interface, while this could be done once and for all by a MultiBridge class.
Why should the caller (either index.php or HTMLUtils if I understand correctly) should be the one loading the data from disk ? Again, the loading code could be implemented once and for all in a MultiBridge class.

Interfaces however clearly state how the "contract" between the caller and callee works, without any distraction of implementation, where abstract classes are much harder to comprehend.

I agree with the clarity of interfaces over abstract classes, but in the case of the MultiBridge interface, it does not apply since the method defined in the interface will always be implemented in the same way for each bridges.
All I wrote above came as long as I read your post. I guess that I should  implement my solution, and then we could compare it to yours to see what would be the more interesting to finally use.

In case you were still waiting for the implementation I proposed above, sorry but I can't find time to work on it for the moment

In case you were still waiting for the implementation I proposed above, sorry but I can't find time to work on it for the moment

Thanks for letting me know. This is not a high priority for me right now, but I still intend to make this work. I have thought a bit about your solution and I'll do some tests myself, though this will have to wait until my next holidays.

I haven't had time to comment on this issue previously, but as I have time now, here it is :
I think that implementing multi-bridge is a good idea, it could be used for bridges providing feeds from sites in different languages, but not using the same code, etc...
However, I strongly disagree on the idea of removing wordpress bridge, and not allowing the use of custom urls.
I think that removes a great functionality of rss-bridge, that is used by many (including me).
Adding a list of valid wordpress bridges will take a lot of time, never be fully complete, and take a lot of maintenance time, and is basically not a valid long term solution.
I do understand, however, the security reasons that motivate your idea, but rss-bridge is never using any 'dangerous' php function, such as exec, etc..., and the only time some arbitrary data are not displayed immediately, they are passed through the json_encode/json_decode function.
Any security issue means that this function has failed, which means a fault in php itself.
I do agree, though, that some people may not want external users to access their rss-bridge instance and fetch arbitrary feeds, which is not possible for the moment. I think we could add an optional HTTP authentication to address this issue, as it is easy to implement and supported by a great majority of feed readers.

However, I strongly disagree on the idea of removing wordpress bridge, and not allowing the use of custom urls.

Me too, though once multi-bridges are implemented, generic bridges can optionally be disabled via the whitelist. That way we get both.
I'll try to get this working before 2017 arrives :sweat_smile:

This is slightly off-topic of course and the proposed solution about derivative bridges sounds great, but I do have one question: a WordPress bridge sounds rather… redundant?

Yes, writing bridges for sites using WordPress is very redundant (as with most CMS I guess). The only thing changing is the URL and maybe a few deviations in the HTML code due to different versions.
Of course having a single bridge accepting any URL is working very well but you loose control to some extend as literally any compatible site can be fetched (including ones you maybe don't want to be associated with).
I still haven't found time (and the urge) to work out a working solution and due to my final exams closing in this will have to wait for quite a bit unfortunately.

The HTML can vary a fair bit with custom themes. I was referring more to the fact that it comes with decent RSS/Atom built in. Even if not explicitly exposed, a /feed at the end of the URL tends to do the trick (or equivalent query string). Of course you could easily kill that if you really wanted to so I guess that must be an issue? :-)

The current WordPress bridge is actually making use of the build in options, see https://github.com/RSS-Bridge/rss-bridge/blob/master/bridges/WordPressBridge.php#L70-L72
If that option is disabled nothing will show up and a custom bridge is necessary.

I've got to say that only makes me more confused as to the purpose of this bridge. What do people use it for?

Good question. I actually don't use it myself. It might be useful to anyone who doesn't know about the /feed option I guess. A lot of sites actually provide carefully hidden feeds with no way to reach them naturally. Being able to just paste the URL and receiving a feed is helpful. Of course now that I think about it instead of building a new feed we could just forward users to the right address without actually downloading random stuff...

Most of wordpress websites are offering truncated RSS feeds.
Using the bridge allows to acess the full content of the articles, instead of just the first few lines.

Ah right, I get it. Thanks for explaining.
Incidentally, is there a generic expander bridge where you just pass a feed and a CSS class to extract?

I started working on this, but never pushed it to RSS-bridge.
If you are interested I can push it.

Yes, definitely. There are actually two "bridges" I've been thinking of adding, although I wasn't completely sure to what extent they'd fit into this project:

A generic expander bridge. That being said, since I switched to FreshRSS last that functionality has been built into my feedreader so it stopped being an active concern.
A generic filter bridge. Because Arte doesn't have per-program feeds, for example, you'd input the whole shebang (see https://github.com/RSS-Bridge/rss-bridge/issues/524#issuecomment-304724282) and filter on title. The initial code would be very simple. In pseudo-code:

if ($action == 'permit') {
	if (preg_match("/$string/", $item->get_title()))
		$display = true;
}
elseif ($action == 'block') {
	if (!preg_match("/$string/", $item->get_title()))
		$display = true;
}

In case it is not obvious - I lost interest in this topic :smile:

authors: Frenzie LogMANOriginal mitsukarenai pmaziere teromene

repo: RSS-Bridge/rss-bridge

license: unlicense


text:
Content-Disposition Header not available in typescript Client

In my Web API method I have added the header as follows:
        System.Net.Mime.ContentDisposition cd = new System.Net.Mime.ContentDisposition
        {
            FileName = "XXXXX.xlsx",
            Inline = false
        };

        this.HttpContext.Response.Headers.Add("Content-Disposition", cd.ToString());

In the response I can see the header as expected in chrome dev tools but it isn't present in the response in the autogenerated client code so this line will always return undefined:
const contentDisposition = response.headers ? response.headers.get("content-disposition") : undefined;
How can I make this header available in the proxy client?

I think you can enable wrapResponses to get response headers... otherwise you probably are not able to read it, except maybe with overriding the process methods...

Similar problem can be caused by next https://stackoverflow.com/questions/52180928/cant-see-headers-of-http-post-angular4

authors: ElGusanito RSuter melnikvitaly

repo: RSuter/NSwag


text:
User should see their avatar as Gravatar (Gravatar API implementation)

Use Gravatar for avatars

Implemented


text:
Semantic HTML style

Issue: Initial file contains only non-semantic elements (div). Best practice is to use semantic elements.
Advice:
Semantic elements - elements with a meaning, which describes its content. Some of the examples are:
article
aside
details
figure
footer
header
main
Requirement: Convert all div elements into semantic elements.

Commit 931ad73 fixed this issue

Completed in commit 9c45f75


text:
[skip ci]hotfix: masterci missing property i

Hot fix for PR #157

👍

:+1:

repo: RackHD/on-build-config