from:"marc"

Re: [PATCH] WIP: rewrite statistics code

2024-07-24 Thread Jean-Marc Lasgouttes


Le 24/07/2024 à 09:43, Jean-Marc Lasgouttes a écrit :

All in all this patch is nice piece of work! :)


Thanks. It needs some cleanup, so I will push it later.


I found the time, the code is now in.

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] WIP: rewrite statistics code

2024-07-24 Thread Jean-Marc Lasgouttes


Le 24/07/2024 à 12:30, Jean-Marc Lasgouttes a écrit :

Le 24/07/2024 à 09:55, Pavel Sanda a écrit :

On Wed, Jul 24, 2024 at 09:43:43AM +0200, Jean-Marc Lasgouttes wrote:
Good, that was the point. The code I proposed to avoid running 
updateMacros on an unchanged document can be used here too.


Are updateMacros called for each caret movement in the document?
If true this might be option how to improve the keyboard movement
speed little bit.


Possibly, I have to check.


The answer is yes ;) But I have a patch for that (trivial to adapt for 
stats).


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[LyX/master] Rewrite statistics code

2024-07-24 Thread Jean-Marc Lasgouttes

commit 6e81f317229a585e4d74b68af967873acd1f74ae
Author: Jean-Marc Lasgouttes 
Date:   Sun Jul 21 22:09:28 2024 +0200

Rewrite statistics code

The statistics code is known to be very slow, because it relies on
DocIterator to go through the buffer.

This commit introduces a new Statistics class that encapsulates the
main code, along a virtual method Inset::updateStatistics() that
allows to fine-tune how counting is done inset by inset.

This is a faithful bug-for-bug reimplementation.

The new code appears to be 3x faster than the old one.

See bug #12929 for a discussion about statistics update woes.
---
 src/Buffer.cpp| 106 +++--
 src/Buffer.h  |  12 ++---
 src/BufferView.cpp|  34 +---
 src/Makefile.am   |   2 +
 src/Statistics.cpp| 120 ++
 src/Statistics.h  |  64 ++
 src/Text.cpp  |  24 -
 src/frontends/qt/GuiView.cpp  |  23 +++-
 src/insets/Inset.cpp  |  14 -
 src/insets/Inset.h|   6 +--
 src/insets/InsetCitation.cpp  |   6 +--
 src/insets/InsetCitation.h|   2 +-
 src/insets/InsetHyperlink.cpp |   8 +--
 src/insets/InsetHyperlink.h   |   2 +-
 src/insets/InsetQuotes.cpp|   5 +-
 src/insets/InsetQuotes.h  |   2 +-
 src/insets/InsetTabular.cpp   |   8 +++
 src/insets/InsetTabular.h |   3 ++
 src/insets/InsetText.cpp  |   7 +++
 src/insets/InsetText.h|   3 ++
 20 files changed, 275 insertions(+), 176 deletions(-)

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index e95d0edcc8..6c1619151c 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -56,7 +56,7 @@
 #include "PDFOptions.h"
 #include "Session.h"
 #include "SpellChecker.h"
-#include "xml.h"
+#include "Statistics.h"
 #include "texstream.h"
 #include "TexRow.h"
 #include "Text.h"
@@ -66,6 +66,7 @@
 #include "VCBackend.h"
 #include "version.h"
 #include "WordLangTuple.h"
+#include "xml.h"
 
 #include "insets/InsetBranch.h"
 #include "insets/InsetInclude.h"
@@ -357,10 +358,8 @@ public:
///
mutable bool need_update;
 
-private:
-   int word_count_;
-   int char_count_;
-   int blank_count_;
+   ///
+   Statistics statistics_;
 
 public:
/// This is here to force the test to be done whenever parent_buffer
@@ -395,22 +394,6 @@ public:
parent_buffer->invalidateBibinfoCache();
}
 
-   /// compute statistics
-   /// \p from initial position
-   /// \p to points to the end position
-   void updateStatistics(DocIterator & from, DocIterator & to,
- bool skipNoOutput = true);
-   /// statistics accessor functions
-   int wordCount() const
-   {
-   return word_count_;
-   }
-   int charCount(bool with_blanks) const
-   {
-   return char_count_
-   + (with_blanks ? blank_count_ : 0);
-   }
-
// Make sure the file monitor monitors the good file.
void refreshFileMonitor();
 
@@ -462,8 +445,7 @@ Buffer::Impl::Impl(Buffer * owner, FileName const & file, 
bool readonly_,
  have_bibitems_(false), lyx_clean(true), bak_clean(true), 
unnamed(false),
  internal_buffer(false), read_only(readonly_), 
file_fully_loaded(false),
  need_format_backup(false), ignore_parent(false), macro_lock(false),
- externally_modified_(false), bibinfo_cache_valid_(false),
- need_update(false), word_count_(0), char_count_(0), blank_count_(0)
+ externally_modified_(false), bibinfo_cache_valid_(false), 
need_update(false)
 {
refreshFileMonitor();
if (!cloned_buffer_) {
@@ -5464,83 +5446,9 @@ void Buffer::requestSpellcheck()
 }
 
 
-void Buffer::Impl::updateStatistics(DocIterator & from, DocIterator & to, bool 
skipNoOutput)
-{
-   bool inword = false;
-   word_count_ = 0;
-   char_count_ = 0;
-   blank_count_ = 0;
-
-   for (DocIterator dit = from ; dit != to && !dit.atEnd(); ) {
-   if (!dit.inTexted()) {
-   dit.forwardPos();
-   continue;
-   }
-
-   Paragraph const & par = dit.paragraph();
-   pos_type const pos = dit.pos();
-
-   // Copied and adapted from isWordSeparator() in Paragraph
-   if (pos == dit.lastpos()) {
-   inword = false;
-   } else {
-   Inset const * ins = par.getInset(pos);
-   if (ins && skipNoOutput && !ins->producesOutput()) {
-   // skip this inset
-

[PATCH v7 1/6] dt-bindings: phy: add qcom,hdmi-phy-8998

2024-07-24 Thread Marc Gonzalez

HDMI PHY block embedded in the APQ8098.

Acked-by: Rob Herring (Arm) 
Acked-by: Vinod Koul 
Signed-off-by: Marc Gonzalez 
---
 Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml 
b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
index 83fe4b39b56f4..78607ee3e2e84 100644
--- a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
@@ -14,6 +14,7 @@ properties:
   compatible:
 enum:
   - qcom,hdmi-phy-8996
+  - qcom,hdmi-phy-8998
 
   reg:
 maxItems: 6

-- 
2.34.1

[PATCH v7 6/6] arm64: dts: qcom: add HDMI nodes for msm8998

2024-07-24 Thread Marc Gonzalez

From: Arnaud Vrac 

Port device nodes from vendor code.

Signed-off-by: Arnaud Vrac 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Marc Gonzalez 
---
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 100 +-
 1 file changed, 99 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index ba5e873f0f35f..1eb15e6d0af4a 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -2785,7 +2785,7 @@ mmcc: clock-controller@c8c {
 <&mdss_dsi0_phy 0>,
 <&mdss_dsi1_phy 1>,
 <&mdss_dsi1_phy 0>,
-<0>,
+<&mdss_hdmi_phy 0>,
 <0>,
 <0>,
 <&gcc GCC_MMSS_GPLL0_DIV_CLK>;
@@ -2890,6 +2890,14 @@ dpu_intf2_out: endpoint {
remote-endpoint = 
<&mdss_dsi1_in>;
};
};
+
+   port@2 {
+   reg = <2>;
+
+   dpu_intf3_out: endpoint {
+   remote-endpoint = 
<&hdmi_in>;
+   };
+   };
};
};
 
@@ -3045,6 +3053,96 @@ mdss_dsi1_phy: phy@c996400 {
 
status = "disabled";
};
+
+   mdss_hdmi: hdmi-tx@c9a {
+   compatible = "qcom,hdmi-tx-8998";
+   reg =   <0x0c9a 0x50c>,
+   <0x0078 0x6220>,
+   <0x0c9e 0x2c>;
+   reg-names = "core_physical",
+   "qfprom_physical",
+   "hdcp_physical";
+
+   interrupt-parent = <&mdss>;
+   interrupts = <8>;
+
+   clocks = <&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_HDMI_CLK>,
+<&mmcc MDSS_HDMI_DP_AHB_CLK>,
+<&mmcc MDSS_EXTPCLK_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MNOC_AHB_CLK>,
+<&mmcc MISC_AHB_CLK>;
+   clock-names =
+   "mdp_core",
+   "iface",
+   "core",
+   "alt_iface",
+   "extp",
+   "bus",
+   "mnoc",
+   "iface_mmss";
+
+   phys = <&mdss_hdmi_phy>;
+   #sound-dai-cells = <1>;
+
+   pinctrl-0 = <&hdmi_hpd_default>,
+   <&hdmi_ddc_default>,
+   <&hdmi_cec_default>;
+   pinctrl-1 = <&hdmi_hpd_sleep>,
+   <&hdmi_ddc_default>,
+   <&hdmi_cec_default>;
+   pinctrl-names = "default", "sleep";
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   hdmi_in: endpoint {
+   remote-endpoint = 
<&dpu_intf3_out>;
+   };
+   };
+
+

[PATCH v7 5/6] arm64: dts: qcom: msm8998: add HDMI GPIOs

2024-07-24 Thread Marc Gonzalez

MSM8998 GPIO pin controller reference design defines:

- CEC: pin 31
- DDC: pin 32,33
- HPD: pin 34

Downstream vendor code for reference:

https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/arch/arm/boot/dts/qcom/msm8998-pinctrl.dtsi#L2324-2400

mdss_hdmi_{cec,ddc,hpd}_{active,suspend}

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Marc Gonzalez 
---
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index e5f051f5a92de..ba5e873f0f35f 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -1434,6 +1434,34 @@ blsp2_spi6_default: blsp2-spi6-default-state {
drive-strength = <6>;
bias-disable;
};
+
+   hdmi_cec_default: hdmi-cec-default-state {
+   pins = "gpio31";
+   function = "hdmi_cec";
+   drive-strength = <2>;
+   bias-pull-up;
+   };
+
+   hdmi_ddc_default: hdmi-ddc-default-state {
+   pins = "gpio32", "gpio33";
+   function = "hdmi_ddc";
+   drive-strength = <2>;
+   bias-pull-up;
+   };
+
+   hdmi_hpd_default: hdmi-hpd-default-state {
+   pins = "gpio34";
+   function = "hdmi_hot";
+   drive-strength = <16>;
+   bias-pull-down;
+   };
+
+   hdmi_hpd_sleep: hdmi-hpd-sleep-state {
+   pins = "gpio34";
+   function = "hdmi_hot";
+   drive-strength = <2>;
+   bias-pull-down;
+   };
};
 
remoteproc_mss: remoteproc@408 {

-- 
2.34.1

[PATCH v7 0/6] HDMI TX support in msm8998

2024-07-24 Thread Marc Gonzalez

DT bits required for HDMI TX support in qcom APQ8098 (MSM8998 cousin)

---
Changes in v7:
- prefix the labels hdmi: and hdmi_phy: with mdss_ (Konrad)
- DID NOT MODIFY patch 3, based on conversation between Conor & Dmitry
- tested 40+40 boots with/without maxcpus=1 => no iommu panic witnessed
- Collect tags from Konrad & Dmitry (hopefully b4 did the right thing)
- Link to v6: 
https://lore.kernel.org/r/20240715-hdmi-tx-v6-0-d27f02962...@freebox.fr

Changes in v6:
- Fold HDMI PHY driver submission into this series
  => [PATCH v2] drm/msm: add msm8998 hdmi phy/pll support
  => Link to v2: 
https://lore.kernel.org/all/20240704-hdmi-phy-v2-1-a7f5af202...@freebox.fr/
 - Rebase onto v6.10
 - Move drivers/gpu/drm/msm/hdmi/hdmi.xml.h to 
drivers/gpu/drm/msm/registers/display/hdmi.xml
 - Add copyright attribution
 - Remove all dead/debug/temporary code
  => Link to v1: 
https://lore.kernel.org/all/63337d63-67ef-4499-8a24-5f6e9285c...@freebox.fr/
- split HDMI PHY driver patch in 2 parts (PHY & TX)
- Use same regulator names as msm8996 (Dmitry)
- Remove printk statements
- Add Vinod's Ack on patch 1
- Expand commit message on patch 4 = HDMI PHY driver
- Link to v5: 
https://lore.kernel.org/r/20240627-hdmi-tx-v5-0-355d5c1fb...@freebox.fr

Changes in v5:
- Fix property & property-names for TX pinctrl in DTSI (Konrad)
- NOT CHANGED: clock trees for TX & PHY based on Dmitry & Jeffrey's remarks
- Link to v4: 
https://lore.kernel.org/r/20240613-hdmi-tx-v4-0-4af17e468...@freebox.fr

Changes in v4:
- Collect tags since v3
- Reword patch 1 subject (Vinod)
- Link to v3: 
https://lore.kernel.org/r/20240606-hdmi-tx-v3-0-9d7feb6d3...@freebox.fr

Changes in v3
- Address Rob's comments on patch 2:
  - 'maxItems: 5' for clocks in the 8996 if/then schema
  - match the order of 8996 for the clock-names in common

---
Arnaud Vrac (2):
  drm/msm: add msm8998 hdmi phy/pll support
  arm64: dts: qcom: add HDMI nodes for msm8998

Marc Gonzalez (4):
  dt-bindings: phy: add qcom,hdmi-phy-8998
  dt-bindings: display/msm: hdmi: add qcom,hdmi-tx-8998
  drm/msm/hdmi: add "qcom,hdmi-tx-8998" compatible
  arm64: dts: qcom: msm8998: add HDMI GPIOs

 .../devicetree/bindings/display/msm/hdmi.yaml  |  28 +-
 .../devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml |   1 +
 arch/arm64/boot/dts/qcom/msm8998.dtsi  | 128 +++-
 drivers/gpu/drm/msm/Makefile   |   1 +
 drivers/gpu/drm/msm/hdmi/hdmi.c|   1 +
 drivers/gpu/drm/msm/hdmi/hdmi.h|   8 +
 drivers/gpu/drm/msm/hdmi/hdmi_phy.c|   5 +
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c   | 779 +
 drivers/gpu/drm/msm/registers/display/hdmi.xml |  89 +++
 9 files changed, 1037 insertions(+), 3 deletions(-)
---
base-commit: 003a26f5074bfe024603cf76f8fd486a5344f307
change-id: 20240606-hdmi-tx-00ee8e7ddbac

Best regards,
-- 
Marc Gonzalez

[PATCH v7 2/6] dt-bindings: display/msm: hdmi: add qcom,hdmi-tx-8998

2024-07-24 Thread Marc Gonzalez

HDMI TX block embedded in the APQ8098.

Reviewed-by: Rob Herring (Arm) 
Reviewed-by: Conor Dooley 
Signed-off-by: Marc Gonzalez 
---
 .../devicetree/bindings/display/msm/hdmi.yaml  | 28 --
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.yaml 
b/Documentation/devicetree/bindings/display/msm/hdmi.yaml
index 47e97669821c3..d4a2033afea8d 100644
--- a/Documentation/devicetree/bindings/display/msm/hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/msm/hdmi.yaml
@@ -19,14 +19,15 @@ properties:
   - qcom,hdmi-tx-8974
   - qcom,hdmi-tx-8994
   - qcom,hdmi-tx-8996
+  - qcom,hdmi-tx-8998
 
   clocks:
 minItems: 1
-maxItems: 5
+maxItems: 8
 
   clock-names:
 minItems: 1
-maxItems: 5
+maxItems: 8
 
   reg:
 minItems: 1
@@ -142,6 +143,7 @@ allOf:
   properties:
 clocks:
   minItems: 5
+  maxItems: 5
 clock-names:
   items:
 - const: mdp_core
@@ -151,6 +153,28 @@ allOf:
 - const: extp
 hdmi-mux-supplies: false
 
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - qcom,hdmi-tx-8998
+then:
+  properties:
+clocks:
+  minItems: 8
+  maxItems: 8
+clock-names:
+  items:
+- const: mdp_core
+- const: iface
+- const: core
+- const: alt_iface
+- const: extp
+- const: bus
+- const: mnoc
+- const: iface_mmss
+
 additionalProperties: false
 
 examples:

-- 
2.34.1

[PATCH v7 6/6] arm64: dts: qcom: add HDMI nodes for msm8998

2024-07-24 Thread Marc Gonzalez

From: Arnaud Vrac 

Port device nodes from vendor code.

Signed-off-by: Arnaud Vrac 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Konrad Dybcio 
Signed-off-by: Marc Gonzalez 
---
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 100 +-
 1 file changed, 99 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index ba5e873f0f35f..1eb15e6d0af4a 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -2785,7 +2785,7 @@ mmcc: clock-controller@c8c {
 <&mdss_dsi0_phy 0>,
 <&mdss_dsi1_phy 1>,
 <&mdss_dsi1_phy 0>,
-<0>,
+<&mdss_hdmi_phy 0>,
 <0>,
 <0>,
 <&gcc GCC_MMSS_GPLL0_DIV_CLK>;
@@ -2890,6 +2890,14 @@ dpu_intf2_out: endpoint {
remote-endpoint = 
<&mdss_dsi1_in>;
};
};
+
+   port@2 {
+   reg = <2>;
+
+   dpu_intf3_out: endpoint {
+   remote-endpoint = 
<&hdmi_in>;
+   };
+   };
};
};
 
@@ -3045,6 +3053,96 @@ mdss_dsi1_phy: phy@c996400 {
 
status = "disabled";
};
+
+   mdss_hdmi: hdmi-tx@c9a {
+   compatible = "qcom,hdmi-tx-8998";
+   reg =   <0x0c9a 0x50c>,
+   <0x0078 0x6220>,
+   <0x0c9e 0x2c>;
+   reg-names = "core_physical",
+   "qfprom_physical",
+   "hdcp_physical";
+
+   interrupt-parent = <&mdss>;
+   interrupts = <8>;
+
+   clocks = <&mmcc MDSS_MDP_CLK>,
+<&mmcc MDSS_AHB_CLK>,
+<&mmcc MDSS_HDMI_CLK>,
+<&mmcc MDSS_HDMI_DP_AHB_CLK>,
+<&mmcc MDSS_EXTPCLK_CLK>,
+<&mmcc MDSS_AXI_CLK>,
+<&mmcc MNOC_AHB_CLK>,
+<&mmcc MISC_AHB_CLK>;
+   clock-names =
+   "mdp_core",
+   "iface",
+   "core",
+   "alt_iface",
+   "extp",
+   "bus",
+   "mnoc",
+   "iface_mmss";
+
+   phys = <&mdss_hdmi_phy>;
+   #sound-dai-cells = <1>;
+
+   pinctrl-0 = <&hdmi_hpd_default>,
+   <&hdmi_ddc_default>,
+   <&hdmi_cec_default>;
+   pinctrl-1 = <&hdmi_hpd_sleep>,
+   <&hdmi_ddc_default>,
+   <&hdmi_cec_default>;
+   pinctrl-names = "default", "sleep";
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   hdmi_in: endpoint {
+   remote-endpoint = 
<&dpu_intf3_out>;
+   };
+   };
+
+

[PATCH v7 5/6] arm64: dts: qcom: msm8998: add HDMI GPIOs

2024-07-24 Thread Marc Gonzalez

MSM8998 GPIO pin controller reference design defines:

- CEC: pin 31
- DDC: pin 32,33
- HPD: pin 34

Downstream vendor code for reference:

https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/arch/arm/boot/dts/qcom/msm8998-pinctrl.dtsi#L2324-2400

mdss_hdmi_{cec,ddc,hpd}_{active,suspend}

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Marc Gonzalez 
---
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index e5f051f5a92de..ba5e873f0f35f 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -1434,6 +1434,34 @@ blsp2_spi6_default: blsp2-spi6-default-state {
drive-strength = <6>;
bias-disable;
};
+
+   hdmi_cec_default: hdmi-cec-default-state {
+   pins = "gpio31";
+   function = "hdmi_cec";
+   drive-strength = <2>;
+   bias-pull-up;
+   };
+
+   hdmi_ddc_default: hdmi-ddc-default-state {
+   pins = "gpio32", "gpio33";
+   function = "hdmi_ddc";
+   drive-strength = <2>;
+   bias-pull-up;
+   };
+
+   hdmi_hpd_default: hdmi-hpd-default-state {
+   pins = "gpio34";
+   function = "hdmi_hot";
+   drive-strength = <16>;
+   bias-pull-down;
+   };
+
+   hdmi_hpd_sleep: hdmi-hpd-sleep-state {
+   pins = "gpio34";
+   function = "hdmi_hot";
+   drive-strength = <2>;
+   bias-pull-down;
+   };
};
 
remoteproc_mss: remoteproc@408 {

-- 
2.34.1

[PATCH v7 4/6] drm/msm: add msm8998 hdmi phy/pll support

2024-07-24 Thread Marc Gonzalez

From: Arnaud Vrac 

Add support for the HDMI PHY as present on the Qualcomm MSM8998 SoC.
This code is mostly copy & paste of the vendor code from msm-4.4
kernel.lnx.4.4.r38-rel.

Signed-off-by: Arnaud Vrac 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Marc Gonzalez 
---
 drivers/gpu/drm/msm/Makefile   |   1 +
 drivers/gpu/drm/msm/hdmi/hdmi.h|   8 +
 drivers/gpu/drm/msm/hdmi/hdmi_phy.c|   5 +
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c   | 779 +
 drivers/gpu/drm/msm/registers/display/hdmi.xml |  89 +++
 5 files changed, 882 insertions(+)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index eb788921ff4fe..b9a5dc8c33ede 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -32,6 +32,7 @@ msm-display-$(CONFIG_DRM_MSM_HDMI) += \
hdmi/hdmi_phy.o \
hdmi/hdmi_phy_8960.o \
hdmi/hdmi_phy_8996.o \
+   hdmi/hdmi_phy_8998.o \
hdmi/hdmi_phy_8x60.o \
hdmi/hdmi_phy_8x74.o \
hdmi/hdmi_pll_8960.o \
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 4586baf364151..a62d2aedfbb72 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -137,6 +137,7 @@ enum hdmi_phy_type {
MSM_HDMI_PHY_8960,
MSM_HDMI_PHY_8x74,
MSM_HDMI_PHY_8996,
+   MSM_HDMI_PHY_8998,
MSM_HDMI_PHY_MAX,
 };
 
@@ -154,6 +155,7 @@ extern const struct hdmi_phy_cfg msm_hdmi_phy_8x60_cfg;
 extern const struct hdmi_phy_cfg msm_hdmi_phy_8960_cfg;
 extern const struct hdmi_phy_cfg msm_hdmi_phy_8x74_cfg;
 extern const struct hdmi_phy_cfg msm_hdmi_phy_8996_cfg;
+extern const struct hdmi_phy_cfg msm_hdmi_phy_8998_cfg;
 
 struct hdmi_phy {
struct platform_device *pdev;
@@ -184,6 +186,7 @@ void __exit msm_hdmi_phy_driver_unregister(void);
 #ifdef CONFIG_COMMON_CLK
 int msm_hdmi_pll_8960_init(struct platform_device *pdev);
 int msm_hdmi_pll_8996_init(struct platform_device *pdev);
+int msm_hdmi_pll_8998_init(struct platform_device *pdev);
 #else
 static inline int msm_hdmi_pll_8960_init(struct platform_device *pdev)
 {
@@ -194,6 +197,11 @@ static inline int msm_hdmi_pll_8996_init(struct 
platform_device *pdev)
 {
return -ENODEV;
 }
+
+static inline int msm_hdmi_pll_8998_init(struct platform_device *pdev)
+{
+   return -ENODEV;
+}
 #endif
 
 /*
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
index 88a3423b7f24d..95b3f7535d840 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
@@ -118,6 +118,9 @@ static int msm_hdmi_phy_pll_init(struct platform_device 
*pdev,
case MSM_HDMI_PHY_8996:
ret = msm_hdmi_pll_8996_init(pdev);
break;
+   case MSM_HDMI_PHY_8998:
+   ret = msm_hdmi_pll_8998_init(pdev);
+   break;
/*
 * we don't have PLL support for these, don't report an error for now
 */
@@ -193,6 +196,8 @@ static const struct of_device_id msm_hdmi_phy_dt_match[] = {
  .data = &msm_hdmi_phy_8x74_cfg },
{ .compatible = "qcom,hdmi-phy-8996",
  .data = &msm_hdmi_phy_8996_cfg },
+   { .compatible = "qcom,hdmi-phy-8998",
+ .data = &msm_hdmi_phy_8998_cfg },
{}
 };
 
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c
new file mode 100644
index 0..9a3b005fa391a
--- /dev/null
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c
@@ -0,0 +1,779 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024 Freebox SAS
+ */
+
+#include 
+#include 
+
+#include "hdmi.h"
+
+#define HDMI_VCO_MAX_FREQ  120UL
+#define HDMI_VCO_MIN_FREQ  80UL
+
+#define HDMI_PCLK_MAX_FREQ 6
+#define HDMI_PCLK_MIN_FREQ 2500
+
+#define HDMI_HIGH_FREQ_BIT_CLK_THRESHOLD   34UL
+#define HDMI_DIG_FREQ_BIT_CLK_THRESHOLD15UL
+#define HDMI_MID_FREQ_BIT_CLK_THRESHOLD75000UL
+#define HDMI_CORECLK_DIV   5
+#define HDMI_DEFAULT_REF_CLOCK 1920
+#define HDMI_PLL_CMP_CNT   1024
+
+#define HDMI_PLL_POLL_MAX_READS100
+#define HDMI_PLL_POLL_TIMEOUT_US   150
+
+#define HDMI_NUM_TX_CHANNEL4
+
+struct hdmi_pll_8998 {
+   struct platform_device *pdev;
+   struct clk_hw clk_hw;
+   unsigned long rate;
+
+   /* pll mmio base */
+   void __iomem *mmio_qserdes_com;
+   /* tx channel base */
+   void __iomem *mmio_qserdes_tx[HDMI_NUM_TX_CHANNEL];
+};
+
+#define hw_clk_to_pll(x) container_of(x, struct hdmi_pll_8998, clk_hw)
+
+struct hdmi_8998_phy_pll_reg_cfg {
+

[PATCH v7 1/6] dt-bindings: phy: add qcom,hdmi-phy-8998

2024-07-24 Thread Marc Gonzalez

HDMI PHY block embedded in the APQ8098.

Acked-by: Rob Herring (Arm) 
Acked-by: Vinod Koul 
Signed-off-by: Marc Gonzalez 
---
 Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml 
b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
index 83fe4b39b56f4..78607ee3e2e84 100644
--- a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
@@ -14,6 +14,7 @@ properties:
   compatible:
 enum:
   - qcom,hdmi-phy-8996
+  - qcom,hdmi-phy-8998
 
   reg:
 maxItems: 6

-- 
2.34.1

[PATCH v7 0/6] HDMI TX support in msm8998

2024-07-24 Thread Marc Gonzalez

DT bits required for HDMI TX support in qcom APQ8098 (MSM8998 cousin)

---
Changes in v7:
- prefix the labels hdmi: and hdmi_phy: with mdss_ (Konrad)
- DID NOT MODIFY patch 3, based on conversation between Conor & Dmitry
- tested 40+40 boots with/without maxcpus=1 => no iommu panic witnessed
- Collect tags from Konrad & Dmitry (hopefully b4 did the right thing)
- Link to v6: 
https://lore.kernel.org/r/20240715-hdmi-tx-v6-0-d27f02962...@freebox.fr

Changes in v6:
- Fold HDMI PHY driver submission into this series
  => [PATCH v2] drm/msm: add msm8998 hdmi phy/pll support
  => Link to v2: 
https://lore.kernel.org/all/20240704-hdmi-phy-v2-1-a7f5af202...@freebox.fr/
 - Rebase onto v6.10
 - Move drivers/gpu/drm/msm/hdmi/hdmi.xml.h to 
drivers/gpu/drm/msm/registers/display/hdmi.xml
 - Add copyright attribution
 - Remove all dead/debug/temporary code
  => Link to v1: 
https://lore.kernel.org/all/63337d63-67ef-4499-8a24-5f6e9285c...@freebox.fr/
- split HDMI PHY driver patch in 2 parts (PHY & TX)
- Use same regulator names as msm8996 (Dmitry)
- Remove printk statements
- Add Vinod's Ack on patch 1
- Expand commit message on patch 4 = HDMI PHY driver
- Link to v5: 
https://lore.kernel.org/r/20240627-hdmi-tx-v5-0-355d5c1fb...@freebox.fr

Changes in v5:
- Fix property & property-names for TX pinctrl in DTSI (Konrad)
- NOT CHANGED: clock trees for TX & PHY based on Dmitry & Jeffrey's remarks
- Link to v4: 
https://lore.kernel.org/r/20240613-hdmi-tx-v4-0-4af17e468...@freebox.fr

Changes in v4:
- Collect tags since v3
- Reword patch 1 subject (Vinod)
- Link to v3: 
https://lore.kernel.org/r/20240606-hdmi-tx-v3-0-9d7feb6d3...@freebox.fr

Changes in v3
- Address Rob's comments on patch 2:
  - 'maxItems: 5' for clocks in the 8996 if/then schema
  - match the order of 8996 for the clock-names in common

---
Arnaud Vrac (2):
  drm/msm: add msm8998 hdmi phy/pll support
  arm64: dts: qcom: add HDMI nodes for msm8998

Marc Gonzalez (4):
  dt-bindings: phy: add qcom,hdmi-phy-8998
  dt-bindings: display/msm: hdmi: add qcom,hdmi-tx-8998
  drm/msm/hdmi: add "qcom,hdmi-tx-8998" compatible
  arm64: dts: qcom: msm8998: add HDMI GPIOs

 .../devicetree/bindings/display/msm/hdmi.yaml  |  28 +-
 .../devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml |   1 +
 arch/arm64/boot/dts/qcom/msm8998.dtsi  | 128 +++-
 drivers/gpu/drm/msm/Makefile   |   1 +
 drivers/gpu/drm/msm/hdmi/hdmi.c|   1 +
 drivers/gpu/drm/msm/hdmi/hdmi.h|   8 +
 drivers/gpu/drm/msm/hdmi/hdmi_phy.c|   5 +
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c   | 779 +
 drivers/gpu/drm/msm/registers/display/hdmi.xml |  89 +++
 9 files changed, 1037 insertions(+), 3 deletions(-)
---
base-commit: 003a26f5074bfe024603cf76f8fd486a5344f307
change-id: 20240606-hdmi-tx-00ee8e7ddbac

Best regards,
-- 
Marc Gonzalez

[PATCH v7 2/6] dt-bindings: display/msm: hdmi: add qcom,hdmi-tx-8998

2024-07-24 Thread Marc Gonzalez

HDMI TX block embedded in the APQ8098.

Reviewed-by: Rob Herring (Arm) 
Reviewed-by: Conor Dooley 
Signed-off-by: Marc Gonzalez 
---
 .../devicetree/bindings/display/msm/hdmi.yaml  | 28 --
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.yaml 
b/Documentation/devicetree/bindings/display/msm/hdmi.yaml
index 47e97669821c3..d4a2033afea8d 100644
--- a/Documentation/devicetree/bindings/display/msm/hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/msm/hdmi.yaml
@@ -19,14 +19,15 @@ properties:
   - qcom,hdmi-tx-8974
   - qcom,hdmi-tx-8994
   - qcom,hdmi-tx-8996
+  - qcom,hdmi-tx-8998
 
   clocks:
 minItems: 1
-maxItems: 5
+maxItems: 8
 
   clock-names:
 minItems: 1
-maxItems: 5
+maxItems: 8
 
   reg:
 minItems: 1
@@ -142,6 +143,7 @@ allOf:
   properties:
 clocks:
   minItems: 5
+  maxItems: 5
 clock-names:
   items:
 - const: mdp_core
@@ -151,6 +153,28 @@ allOf:
 - const: extp
 hdmi-mux-supplies: false
 
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - qcom,hdmi-tx-8998
+then:
+  properties:
+clocks:
+  minItems: 8
+  maxItems: 8
+clock-names:
+  items:
+- const: mdp_core
+- const: iface
+- const: core
+- const: alt_iface
+- const: extp
+- const: bus
+- const: mnoc
+- const: iface_mmss
+
 additionalProperties: false
 
 examples:

-- 
2.34.1

[PATCH v7 3/6] drm/msm/hdmi: add "qcom,hdmi-tx-8998" compatible

2024-07-24 Thread Marc Gonzalez

Current driver already supports the msm8998 HDMI TX.
We just need to add the compatible string.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Marc Gonzalez 
---
 drivers/gpu/drm/msm/hdmi/hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 24abcb7254cc4..0bfee41c2e71a 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -549,6 +549,7 @@ static void msm_hdmi_dev_remove(struct platform_device 
*pdev)
 }
 
 static const struct of_device_id msm_hdmi_dt_match[] = {
+   { .compatible = "qcom,hdmi-tx-8998", .data = &hdmi_tx_8974_config },
{ .compatible = "qcom,hdmi-tx-8996", .data = &hdmi_tx_8974_config },
{ .compatible = "qcom,hdmi-tx-8994", .data = &hdmi_tx_8974_config },
{ .compatible = "qcom,hdmi-tx-8084", .data = &hdmi_tx_8974_config },

-- 
2.34.1

[PATCH v7 3/6] drm/msm/hdmi: add "qcom,hdmi-tx-8998" compatible

2024-07-24 Thread Marc Gonzalez

Current driver already supports the msm8998 HDMI TX.
We just need to add the compatible string.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Marc Gonzalez 
---
 drivers/gpu/drm/msm/hdmi/hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 24abcb7254cc4..0bfee41c2e71a 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -549,6 +549,7 @@ static void msm_hdmi_dev_remove(struct platform_device 
*pdev)
 }
 
 static const struct of_device_id msm_hdmi_dt_match[] = {
+   { .compatible = "qcom,hdmi-tx-8998", .data = &hdmi_tx_8974_config },
{ .compatible = "qcom,hdmi-tx-8996", .data = &hdmi_tx_8974_config },
{ .compatible = "qcom,hdmi-tx-8994", .data = &hdmi_tx_8974_config },
{ .compatible = "qcom,hdmi-tx-8084", .data = &hdmi_tx_8974_config },

-- 
2.34.1

[PATCH v7 4/6] drm/msm: add msm8998 hdmi phy/pll support

2024-07-24 Thread Marc Gonzalez

From: Arnaud Vrac 

Add support for the HDMI PHY as present on the Qualcomm MSM8998 SoC.
This code is mostly copy & paste of the vendor code from msm-4.4
kernel.lnx.4.4.r38-rel.

Signed-off-by: Arnaud Vrac 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Marc Gonzalez 
---
 drivers/gpu/drm/msm/Makefile   |   1 +
 drivers/gpu/drm/msm/hdmi/hdmi.h|   8 +
 drivers/gpu/drm/msm/hdmi/hdmi_phy.c|   5 +
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c   | 779 +
 drivers/gpu/drm/msm/registers/display/hdmi.xml |  89 +++
 5 files changed, 882 insertions(+)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index eb788921ff4fe..b9a5dc8c33ede 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -32,6 +32,7 @@ msm-display-$(CONFIG_DRM_MSM_HDMI) += \
hdmi/hdmi_phy.o \
hdmi/hdmi_phy_8960.o \
hdmi/hdmi_phy_8996.o \
+   hdmi/hdmi_phy_8998.o \
hdmi/hdmi_phy_8x60.o \
hdmi/hdmi_phy_8x74.o \
hdmi/hdmi_pll_8960.o \
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 4586baf364151..a62d2aedfbb72 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -137,6 +137,7 @@ enum hdmi_phy_type {
MSM_HDMI_PHY_8960,
MSM_HDMI_PHY_8x74,
MSM_HDMI_PHY_8996,
+   MSM_HDMI_PHY_8998,
MSM_HDMI_PHY_MAX,
 };
 
@@ -154,6 +155,7 @@ extern const struct hdmi_phy_cfg msm_hdmi_phy_8x60_cfg;
 extern const struct hdmi_phy_cfg msm_hdmi_phy_8960_cfg;
 extern const struct hdmi_phy_cfg msm_hdmi_phy_8x74_cfg;
 extern const struct hdmi_phy_cfg msm_hdmi_phy_8996_cfg;
+extern const struct hdmi_phy_cfg msm_hdmi_phy_8998_cfg;
 
 struct hdmi_phy {
struct platform_device *pdev;
@@ -184,6 +186,7 @@ void __exit msm_hdmi_phy_driver_unregister(void);
 #ifdef CONFIG_COMMON_CLK
 int msm_hdmi_pll_8960_init(struct platform_device *pdev);
 int msm_hdmi_pll_8996_init(struct platform_device *pdev);
+int msm_hdmi_pll_8998_init(struct platform_device *pdev);
 #else
 static inline int msm_hdmi_pll_8960_init(struct platform_device *pdev)
 {
@@ -194,6 +197,11 @@ static inline int msm_hdmi_pll_8996_init(struct 
platform_device *pdev)
 {
return -ENODEV;
 }
+
+static inline int msm_hdmi_pll_8998_init(struct platform_device *pdev)
+{
+   return -ENODEV;
+}
 #endif
 
 /*
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
index 88a3423b7f24d..95b3f7535d840 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
@@ -118,6 +118,9 @@ static int msm_hdmi_phy_pll_init(struct platform_device 
*pdev,
case MSM_HDMI_PHY_8996:
ret = msm_hdmi_pll_8996_init(pdev);
break;
+   case MSM_HDMI_PHY_8998:
+   ret = msm_hdmi_pll_8998_init(pdev);
+   break;
/*
 * we don't have PLL support for these, don't report an error for now
 */
@@ -193,6 +196,8 @@ static const struct of_device_id msm_hdmi_phy_dt_match[] = {
  .data = &msm_hdmi_phy_8x74_cfg },
{ .compatible = "qcom,hdmi-phy-8996",
  .data = &msm_hdmi_phy_8996_cfg },
+   { .compatible = "qcom,hdmi-phy-8998",
+ .data = &msm_hdmi_phy_8998_cfg },
{}
 };
 
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c
new file mode 100644
index 0..9a3b005fa391a
--- /dev/null
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c
@@ -0,0 +1,779 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024 Freebox SAS
+ */
+
+#include 
+#include 
+
+#include "hdmi.h"
+
+#define HDMI_VCO_MAX_FREQ  120UL
+#define HDMI_VCO_MIN_FREQ  80UL
+
+#define HDMI_PCLK_MAX_FREQ 6
+#define HDMI_PCLK_MIN_FREQ 2500
+
+#define HDMI_HIGH_FREQ_BIT_CLK_THRESHOLD   34UL
+#define HDMI_DIG_FREQ_BIT_CLK_THRESHOLD15UL
+#define HDMI_MID_FREQ_BIT_CLK_THRESHOLD75000UL
+#define HDMI_CORECLK_DIV   5
+#define HDMI_DEFAULT_REF_CLOCK 1920
+#define HDMI_PLL_CMP_CNT   1024
+
+#define HDMI_PLL_POLL_MAX_READS100
+#define HDMI_PLL_POLL_TIMEOUT_US   150
+
+#define HDMI_NUM_TX_CHANNEL4
+
+struct hdmi_pll_8998 {
+   struct platform_device *pdev;
+   struct clk_hw clk_hw;
+   unsigned long rate;
+
+   /* pll mmio base */
+   void __iomem *mmio_qserdes_com;
+   /* tx channel base */
+   void __iomem *mmio_qserdes_tx[HDMI_NUM_TX_CHANNEL];
+};
+
+#define hw_clk_to_pll(x) container_of(x, struct hdmi_pll_8998, clk_hw)
+
+struct hdmi_8998_phy_pll_reg_cfg {
+

[MariaDB discuss] Re: possible bug in dropping max connections

2024-07-24 Thread Marc via discuss

> >
> > > Not quite. max_user_connections limit is enforced after successful
> > > authentication - that's when the server knows the user name.
> > >
> > > max_connections is enforced as soon as the client connects.
> > >
> > > So yes, even when usera has reached max_user_connections limit, they
> > > can keep trying to connect and exhaust max_connections too,
> > > especially if they'll delay sending authentication packets.
> >
> > So what about waiting a bit with dropping the connection of
> > max_connections, so you can do
> >
> > - get the send user name
> > - check if the username is in max_user_connections limit
> > - if it is limited drop the connection, but don't add it to the
> > max_connections counter.
> > - if it is not limited add the connection, and add it to
> > max_connections counter.
> >
> > disadvantage
> > - is when you drop the connection for max_connections. You have to
> > maybe postpone this a bit.
> > - could this postponing be abused in a dos attack?
> 
> Yes, it could. Currently when usera has reached max_user_connections
> limit, they can keep trying to connect and exhaust max_connections too,
> especially if they'll delay sending authentication packets.

But you already have timeouts for this not? I think that is a separate case.

> If the server will delay enforcing of max_connections (that is, the
> server will not reject connections about max_connections at once),
> then this user in the above scenario will open all possible connections

Really? Mostly you need to delay until the n'th packet is received with the 
username. Besides you mostly are also processing requests from 'badly' 
operating clients. Who are not trying to dos the db server with some malformed 
tcp stream. These clients just send to many requests for whatever reason. So in 
~90% of the cases you will just receive the username as with any 'normal' 
connection.

What delay are we then talking about? I assume the delay between initiating a 
connection and receiving the username is in the low ms?

> your OS can handle and the computer will become completely inaccessible.

Besides is the limits.conf or so from your os not limiting the ports. I don't 
think it is currently that easy for a process to cause a dos on the os.

> Currently only the MariaDB server will become inaccessible, but you can
> configure extra_port to always be able to access the server in such a
> case.

Yes, I am now restarting it even. The idea about this change is to have a more 
useful and expected implementation of max_user_connections and max_connections. 
Currently I am using max_connections not for what it is supposed to be used, 
just because the max_user_connections is not doing as much as it 'should'.







___
discuss mailing list -- discuss@lists.mariadb.org
To unsubscribe send an email to discuss-le...@lists.mariadb.org

Re: LyX user file in linux

2024-07-24 Thread Jean-Marc Lasgouttes


Le 24/07/2024 à 15:36, Jürgen Spitzmüller a écrit :

Am Mittwoch, dem 24.07.2024 um 10:40 +0100 schrieb José Matos:

What do you think? Any idea about this?


Since I do access it often, I am personally not too fond of having it
hidden deeper down the hierarchy.

I also think some external programs (bibliography managers) have the
path to the personal directory (lyxpipes) stored (although this is
probably customizable in those apps, it will break the workflow).


I agree with Juergen that the gain is dubious, but there is a non 
negligible price to pay.


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

RE: sieve mail date change

2024-07-24 Thread Marc via dovecot

> > I am a bit rookie with sieve. Some time ago I created a sieve pipe that
> would sometimes alter alter the subject and move a message to a different
> mailbox. Currently this results in that a date changes of this message
> while I don't see anything in the source altering a date.
> >
> > What could be causing this and how to work around this?
> 
> 
> can you show info that might be useful to understand the issue you are
> facing? For example, what are the contents of the sieve script? When is
> the script being executed (for example on mail delivery by lmtp/lda)?
> When you say the date changes of the message can you give an example of
> what you are seeing?
> 

I have been checking this a bit furhter and it is seems this behaviour is 
limited to the apple mail client ... I can't replicate this behaviour at least 
via the webmail interface. 
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

[Bug 2073942] Re: Fox News Site Not Working

2024-07-24 Thread Marc Deslauriers

** Package changed: apache2 (Ubuntu) => firefox (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073942

Title:
  Fox News Site Not Working

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2073942/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [PATCH v3 0/2] Consolidate create-sync and create-fence

2024-07-24 Thread Marc-André Lureau

Hi

On Wed, Jul 24, 2024 at 2:05 AM  wrote:

> From: Dongwon Kim 
>
> Sync object itself is never used as is so can be removed
> from QemuDmaBuf struct. So now sync is only temporarily needed
> when creating fence for the object which means what was done in
> egl_dmabuf_create_sync can now be a part of egl_dmabuf_create_fence
> function. And egl_dmabuf_create_fence returns fence_fd so the
> better function name will be egl_dmabuf_create_fence_fd.
>
> v3: create fence only if current QemuDmaBuf->fence_fd = -1
> to make sure there is no fence currently bound to the
> QemuDmaBuf
>

Why not check it from egl_dmabuf_create_fence_fd() ? calling the function
twice can still potentially leak.

Also, please gather the v1/v2/v3/... summary on the cover letter.

thanks


> Dongwon Kim (2):
>   ui/egl-helpers: Consolidates create-sync and create-fence
>   ui/dmabuf: Remove 'sync' from QemuDmaBuf struct
>
>  include/ui/dmabuf.h  |  2 --
>  include/ui/egl-helpers.h |  3 +--
>  ui/dmabuf.c  | 14 --
>  ui/egl-helpers.c | 24 +---
>  ui/gtk-egl.c | 17 -
>  ui/gtk-gl-area.c | 12 +++-
>  6 files changed, 17 insertions(+), 55 deletions(-)
>
> --
> 2.43.0
>
>
>

-- 
Marc-André Lureau

Re: [PATCH] WIP: rewrite statistics code

2024-07-24 Thread Jean-Marc Lasgouttes


Le 24/07/2024 à 09:55, Pavel Sanda a écrit :

On Wed, Jul 24, 2024 at 09:43:43AM +0200, Jean-Marc Lasgouttes wrote:

Good, that was the point. The code I proposed to avoid running updateMacros on 
an unchanged document can be used here too.


Are updateMacros called for each caret movement in the document?
If true this might be option how to improve the keyboard movement
speed little bit.


Possibly, I have to check.

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH v2] chardev/char-win-stdio.c: restore old console mode

2024-07-24 Thread Marc-André Lureau

Hi

On Wed, Jul 24, 2024 at 8:48 AM Michael Tokarev  wrote:

> 22.07.2024 12:52, songziming wrote:
> > If I use `-serial stdio` on Windows, after QEMU exits, the terminal
> > could not handle arrow keys and tab any more. Because stdio backend
> > on Windows sets console mode to virtual terminal input when starts,
> > but does not restore the old mode when finalize.
> >
> > This small patch saves the old console mode and set it back.
>
> Is this a stable@ material?
>

It should be safe, but I don't think it deserves a stable backport: it
always had that behaviour before.

-- 
Marc-André Lureau

[389-users] Re: where to find doc "What's new in 389-DS" last releases

2024-07-24 Thread Marc Sauton

If your are looking specifically for the RHEL-9 and RHEL-8 's 389-ds or
RHDS-12 and RHDS-11 , I will point to the RHEL release notes ( port389.org
is the upstream project ):

RHEL-9 IdM
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/9.4_release_notes/new-features#new-features-identity-management
389-ds-base rebased to version 2.4.5
The 389-ds-base package has been updated to version 2.4.5. Notable bug
fixes and enhancements over version 2.3.4 include:
...
The HAProxy protocol is now supported for the 389-ds-base package
...

RHEL-8 IdM
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/8.10_release_notes/new-features#new-features-identity-management
389-ds-base rebased to version 1.4.3.39
...

RHDS-12 on RHEL-9
https://docs.redhat.com/en/documentation/red_hat_directory_server/12/html/red_hat_directory_server_12_release_notes

RHDS-11 on RHEL-8
https://docs.redhat.com/en/documentation/red_hat_directory_server/11/html/release_notes


On Tue, Jul 23, 2024 at 1:09 PM Mark Reynolds  wrote:

>
> On 7/23/24 2:38 PM, Ghiurea, Isabella wrote:
>
> Thank you Mark , one of the link bellow  seems is not working
>
> https://www.port389.org/docs/389ds/design/slapi-memberof.html
>
> Thanks for the heads up, we will look into it shortly!
>
> --
> *From:* Mark Reynolds  
> *Sent:* Tuesday, July 23, 2024 11:18:44 AM
> *To:* General discussion list for the 389 Directory server project.;
> Ghiurea, Isabella
> *Subject:* Re: [389-users] where to find doc "What's new in 389-DS" last
> releases
>
>
> Attention*** This email originated from outside of the NRC.
> ***Attention*** Ce courriel provient de l'extérieur du CNRC.*
>
> Hi Ghiurea,
>
>
> If you got Documentation and then Design Docs you will see where new
> features are recorded:
>
>
> https://www.port389.org/docs/389ds/design/design.html
>
>
> This page should be accurate, but I suspect some changes might slip
> through the cracks.  Either way that's all we got besides looking at RHEL
> release notes.
>
>
> HTH,
> Mark
>
>
> On 7/23/24 1:53 PM, Ghiurea, Isabella wrote:
>
> Hello User 389-ds,
>
>  I am looking over 389-ds.org website can not find the link to whats new
> in last versions for 389-ds for RHEL 8/9 ? I know there are bug fixes but
> how about what has been changed or new functionality ?
>
> thanks
>
> --
> Identity Management Development Team
>
> --
> Identity Management Development Team
>
> --
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [PATCH] WIP: rewrite statistics code

2024-07-24 Thread Jean-Marc Lasgouttes



Le 24 juillet 2024 01:57:01 GMT+02:00, Pavel Sanda  a écrit :
>I tested and do not see any counting difference in my selected document and
>confirm that profiling gives about 3x better time with your patch.

Thanks for testing. To be frank, I have been disappointed at first to have 
"only" a 3x speedup :) I am not sure how to improve on that, but that's 
probably ok.

The take away is: don't use forwardPar to iterate a document (yes updateMacros, 
I'm looking at you!).

>On top of that this speed up was good enough that I do not see visually
>noticeable hiccups while moving with the cursor in User Guide anymore - but
>that's also due to the fact that cursor moving is still somewhat slow on fast
>repeat rates compared to other editors or terminals I have, heh ;). 

Good, that was the point. The code I proposed to avoid running updateMacros on 
an unchanged document can be used here too.

>All in all this patch is nice piece of work! :)

Thanks. It needs some cleanup, so I will push it later.

>Is the original problem reported on users list solved by this rewrite
>or the lags created by citations are currently solved only by disabling
>the stat feature anyway?

Jürgen took care of this one 

JMarc 
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Do not export the content of InsetMathBoxed as text in MathML

2024-07-23 Thread Jean-Marc Lasgouttes


Le 23/07/2024 à 23:48, Jean-Marc Lasgouttes a écrit :

commit 1186d90edf9a6702573f296d5642c5e61ceaaedf
Author: Jean-Marc Lasgouttes 
Date:   Tue Jul 23 23:44:58 2024 +0200

 Do not export the content of InsetMathBoxed as text in MathML
 
 \boxed{} is the only box in LaTeX that contains math. It is amusing

 that the example file that we had for ticket #13609 should not have
 been a problem since there is no reason to force  there.



Riki, this is candidate for branch.

JMarc



---
  src/mathed/InsetMathBox.cpp | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mathed/InsetMathBox.cpp b/src/mathed/InsetMathBox.cpp
index f06ffcf95d..62a11a15aa 100644
--- a/src/mathed/InsetMathBox.cpp
+++ b/src/mathed/InsetMathBox.cpp
@@ -402,7 +402,9 @@ void InsetMathBoxed::infoize(odocstream & os) const
  
  void InsetMathBoxed::mathmlize(MathMLStream & ms) const

  {
-   mathmlizeHelper(ms, cell(0), "class='boxed'");
+   ms << MTag("mrow", "class='boxed'");
+   ms << cell(0);
+   ms << ETag("mrow");
  }
  
  


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Fixup 216a6fb348: close when quitting text mode

2024-07-23 Thread Jean-Marc Lasgouttes


Le 23/07/2024 à 22:11, Jean-Marc Lasgouttes a écrit :

commit 1385f0fddd0229770496b1e50b76782892032d18
Author: Jean-Marc Lasgouttes 
Date:   Tue Jul 23 22:02:50 2024 +0200

 Fixup 216a6fb348: close  when quitting text mode
 
 This fixes malformed documents on UserGuide export.
 
 Related to bug #13069.


Riki, this is candidate for branch.

JMarc


---
  src/mathed/MathStream.cpp | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/mathed/MathStream.cpp b/src/mathed/MathStream.cpp
index 2951aeeefd..665b3fcbf4 100644
--- a/src/mathed/MathStream.cpp
+++ b/src/mathed/MathStream.cpp
@@ -547,6 +547,7 @@ SetMode::SetMode(MathMLStream & ms, bool text)
  
  SetMode::~SetMode()

  {
+   ms_.beforeTag();
ms_.text_level_ = old_text_level_;
  }
  


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Fixup 216a6fb3: fix broken xml syntax

2024-07-23 Thread Jean-Marc Lasgouttes


Le 23/07/2024 à 19:52, Jean-Marc Lasgouttes a écrit :

commit a268fe096a58a7818554a7da4da85896bb289c81
Author: Jean-Marc Lasgouttes 
Date:   Tue Jul 23 15:04:49 2024 +0200

 Fixup 216a6fb3: fix broken xml syntax
 
 This commit addresses two issues:
 
 1/ the embarassing one: the member SetMode::old_text_level_ was

declared as bool instead of int. This means that is was definitely
not a proper backup variable!
 
 2/ a robustness issue: replace two consecutive test for isTest() by a

boolean veriable that is used twice. This makes sure that 
cannot be output without the corresponding .
 
 Part of bug #13069.


Riki, this is candidate for branch.

JMarc


---
  src/mathed/MathExtern.cpp | 6 --
  src/mathed/MathStream.h   | 2 +-
  2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/mathed/MathExtern.cpp b/src/mathed/MathExtern.cpp
index 1f9356f8f2..990d35e9d2 100644
--- a/src/mathed/MathExtern.cpp
+++ b/src/mathed/MathExtern.cpp
@@ -1646,11 +1646,13 @@ void mathmlize(MathData const & dat, MathMLStream & ms)
} else if (ar.size() == 1) {
ms << ar.front();
} else {
-   if (!ms.inText())
+   // protect against the value changing in the second test.
+   bool const intext = ms.inText();
+   if (!intext)
ms << MTag("mrow");
for (MathData::const_iterator it = ar.begin(); it != ar.end(); 
++it)
(*it)->mathmlize(ms);
-   if (!ms.inText())
+   if (!intext)
ms << ETag("mrow");
}
  }
diff --git a/src/mathed/MathStream.h b/src/mathed/MathStream.h
index a9edae08c0..40bb7d3bfb 100644
--- a/src/mathed/MathStream.h
+++ b/src/mathed/MathStream.h
@@ -469,7 +469,7 @@ private:
///
MathMLStream & ms_;
///
-   bool old_text_level_;
+   int old_text_level_;
  };
  
  


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[LyX/master] Do not export the content of InsetMathBoxed as text in MathML

2024-07-23 Thread Jean-Marc Lasgouttes

commit 1186d90edf9a6702573f296d5642c5e61ceaaedf
Author: Jean-Marc Lasgouttes 
Date:   Tue Jul 23 23:44:58 2024 +0200

Do not export the content of InsetMathBoxed as text in MathML

\boxed{} is the only box in LaTeX that contains math. It is amusing
that the example file that we had for ticket #13609 should not have
been a problem since there is no reason to force  there.
---
 src/mathed/InsetMathBox.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mathed/InsetMathBox.cpp b/src/mathed/InsetMathBox.cpp
index f06ffcf95d..62a11a15aa 100644
--- a/src/mathed/InsetMathBox.cpp
+++ b/src/mathed/InsetMathBox.cpp
@@ -402,7 +402,9 @@ void InsetMathBoxed::infoize(odocstream & os) const
 
 void InsetMathBoxed::mathmlize(MathMLStream & ms) const
 {
-   mathmlizeHelper(ms, cell(0), "class='boxed'");
+   ms << MTag("mrow", "class='boxed'");
+   ms << cell(0);
+   ms << ETag("mrow");
 }
 
 
-- 
lyx-cvs mailing list
lyx-cvs@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-cvs

Re: [PATCH v2] MATCH: Add simplification for MAX and MIN to match.pd [PR109878]

2024-07-23 Thread Marc Glisse

A few ideas in case you want to generalize the transformation (these are 
not requirements to get your patch in, and this is not a review):


On Fri, 19 Jul 2024, Eikansh Gupta wrote:


--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4321,6 +4321,32 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
@0
@2)))

+/* min (a & CST0, a & CST1) -> a & CST0 IFF CST0 & CST1 == CST0 */
+/* max (a & CST0, a & CST1) -> a & CST0 IFF CST0 & CST1 == CST1 */
+/* If signed a, then both the constants should have same sign. */
+(for minmax (min max)
+ (simplify
+  (minmax (bit_and@3 @0 INTEGER_CST@1) (bit_and@4 @0 INTEGER_CST@2))
+   (if (TYPE_UNSIGNED (type)
+|| (tree_int_cst_sgn (@1) == tree_int_cst_sgn (@2)))
+(with { auto andvalue = wi::to_wide (@1) & wi::to_wide (@2); }
+ (if (andvalue == ((minmax == MIN_EXPR)
+   ? wi::to_wide (@1) : wi::to_wide (@2)))
+  @3
+  (if (andvalue == ((minmax != MIN_EXPR)
+? wi::to_wide (@1) : wi::to_wide (@2)))
+   @4))


Since max(a&1,a&3) is a&3, I think in the signed case we could also 
replace max(a&N,a&3) with a&3 if N is 1 | sign-bit (i.e. -1u/2+2). Indeed, 
either a>=0 and a&N is a&1, or a<0 and a&N < 0 <= a&3.



+/* min (a, a & CST) --> a & CST */
+/* max (a, a & CST) --> a */
+(for minmax (min max)
+ (simplify
+  (minmax @0 (bit_and@1 @0 INTEGER_CST@2))


Why do you require that @2 be a constant?


+   (if (TYPE_UNSIGNED(type))
+(if (minmax == MIN_EXPR)
+ @1
+ @0


Do we already have the corresponding transformations for comparisons?

a&b <= a --> true (if unsigned)
etc

Ideally, we would have **1** transformation for max(X,Y) that tries to 
fold X<=Y and if it folds to true then simplifies to Y. This way the 
transformations would only need to be written for comparisons, not minmax.


--
Marc Glisse

Re: Many xhtml/docbook tests now failing on master

2024-07-23 Thread Jean-Marc Lasgouttes


Le 23/07/2024 à 22:22, Scott Kostyshak a écrit :

On Tue, Jul 23, 2024 at 04:14:28PM GMT, Scott Kostyshak wrote:

On Tue, Jul 23, 2024 at 10:12:32PM GMT, Jean-Marc Lasgouttes wrote:

Le 23/07/2024 à 21:11, Scott Kostyshak a écrit :

I believe this one is very recent:

export/doc/UserGuide_xhtml

This corresponds to the English user guide.


This one was easy. Do you have another one for me?


I'll rerun the tests now and let you know.


All xhtml tests seem to pass for me except for the 6 tests that are timing out.


Great! Thanks for the help. For some reason it did not came to my mind 
to just export files and look at what happens %-|


I'll continue to export random manuals.

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Many xhtml/docbook tests now failing on master

2024-07-23 Thread Jean-Marc Lasgouttes


Le 23/07/2024 à 21:11, Scott Kostyshak a écrit :

I believe this one is very recent:

   export/doc/UserGuide_xhtml

This corresponds to the English user guide.


This one was easy. Do you have another one for me?

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[LyX/master] Fixup 216a6fb348: close when quitting text mode

2024-07-23 Thread Jean-Marc Lasgouttes

commit 1385f0fddd0229770496b1e50b76782892032d18
Author: Jean-Marc Lasgouttes 
Date:   Tue Jul 23 22:02:50 2024 +0200

Fixup 216a6fb348: close  when quitting text mode

This fixes malformed documents on UserGuide export.

Related to bug #13069.
---
 src/mathed/MathStream.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mathed/MathStream.cpp b/src/mathed/MathStream.cpp
index 2951aeeefd..665b3fcbf4 100644
--- a/src/mathed/MathStream.cpp
+++ b/src/mathed/MathStream.cpp
@@ -547,6 +547,7 @@ SetMode::SetMode(MathMLStream & ms, bool text)
 
 SetMode::~SetMode()
 {
+   ms_.beforeTag();
ms_.text_level_ = old_text_level_;
 }
 
-- 
lyx-cvs mailing list
lyx-cvs@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-cvs

[Bug 1999814] Re: [SRU] Allow for specifying common baseline CPU model with disabled feature

2024-07-23 Thread Marc Deslauriers

Unfortunately the nova package in jammy-proposed got superseded by a
security update and will have to be re-uploaded.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1999814

Title:
  [SRU] Allow for specifying common baseline CPU model with disabled
  feature

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1999814/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[USN-6911-1] Nova vulnerability

2024-07-23 Thread Marc Deslauriers


==
Ubuntu Security Notice USN-6911-1
July 23, 2024

nova vulnerability
==

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 24.04 LTS
- Ubuntu 22.04 LTS
- Ubuntu 20.04 LTS

Summary:

Nova would allow unintended access to files over the network.

Software Description:
- nova: OpenStack Compute cloud infrastructure

Details:

Arnaud Morin discovered that Nova incorrectly handled certain raw format
images. An authenticated user could use this issue to access arbitrary
files on the server, possibly exposing sensitive information.

Update instructions:

The problem can be corrected by updating your system to the following
package versions:

Ubuntu 24.04 LTS
  nova-common 3:29.0.1-0ubuntu1.4
  python3-nova3:29.0.1-0ubuntu1.4

Ubuntu 22.04 LTS
  nova-common 3:25.2.1-0ubuntu2.6
  python3-nova3:25.2.1-0ubuntu2.6

Ubuntu 20.04 LTS
  nova-common 2:21.2.4-0ubuntu2.11
  python3-nova2:21.2.4-0ubuntu2.11

In general, a standard system update will make all the necessary changes.

References:
  https://ubuntu.com/security/notices/USN-6911-1
  CVE-2024-40767

Package Information:
  https://launchpad.net/ubuntu/+source/nova/3:29.0.1-0ubuntu1.4
  https://launchpad.net/ubuntu/+source/nova/3:25.2.1-0ubuntu2.6
  https://launchpad.net/ubuntu/+source/nova/2:21.2.4-0ubuntu2.11



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Many xhtml/docbook tests now failing on master

2024-07-23 Thread Jean-Marc Lasgouttes


Le 23/07/2024 à 21:11, Kornel Benko a écrit :

Am Tue, 23 Jul 2024 20:47:03 +0200
schrieb Jean-Marc Lasgouttes :


Le 23/07/2024 à 20:23, Kornel Benko a écrit :

  From the 132 previously failed tests now are only 54 test failing.
Some of the first are:
59% tests passed, 54 tests failed out of 132
The following tests FAILED:
300 - export/export/docbook/basic_xhtml (Failed)
306 - export/export/docbook/bibliography_precooked_aastex_xhtml (Failed)
365 - export/export/docbook/svmono_xhtml (Failed)
367 - export/export/docbook/svmono_light_xhtml (Failed)
369 - export/export/docbook/svmult_xhtml (Failed)
1762 - export/export/xhtml/math_output_latex_docbook5 (Failed)
1866 - export/doc/EmbeddedObjects_xhtml (Failed)
1884 - export/doc/Formula-numbering_xhtml (Failed)
1956 - export/doc/Math_xhtml (Failed)
2015 - export/doc/UserGuide_xhtml (Failed)
2060 - export/doc/ar/UserGuide_xhtml (Failed)
2213 - export/doc/de/EmbeddedObjects_xhtml (Failed)
2231 - export/doc/de/Formelnummerierung_xhtml (Failed)
2267 - export/doc/de/Math_xhtml (Failed)
...


Where do I find the corresponding tests? I really know nothing about tests.


You would have to use cmake-build configured with
-DLYX_ENABLE_EXPORT_TESTS:BOOL=ON

In the build-directory you can then use ctest


Also, does failing mean that there is a parsing error, or that the
output is now different?


Mostly parsing error as a result of /usr/bin/xmllint on the exported .xml-file.


It would be great if you could point me to a few newly broken lyx files 
:) I do not have a working cmake build here.


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Many xhtml/docbook tests now failing on master

2024-07-23 Thread Jean-Marc Lasgouttes


Le 23/07/2024 à 20:53, Scott Kostyshak a écrit :

I have 60 xhtml tests failing on current master now. Some are timing out
so that might be a good place to start. For example, the following
export times out for me after 10 minutes:

cd lib/examples/Curricula_Vitae && lyx -e xhtml Modern_CV.lyx


The debugger points to BiblioInfo;::getInfo. When I try the same with a 
tree without my patches, I have the same issue.


Could you try with a tree from a few days ago and tell me what are the 
newly broken tests?


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Many xhtml/docbook tests now failing on master

2024-07-23 Thread Jean-Marc Lasgouttes


Le 23/07/2024 à 20:23, Kornel Benko a écrit :

 From the 132 previously failed tests now are only 54 test failing.
Some of the first are:
59% tests passed, 54 tests failed out of 132
The following tests FAILED:
300 - export/export/docbook/basic_xhtml (Failed)
306 - export/export/docbook/bibliography_precooked_aastex_xhtml (Failed)
365 - export/export/docbook/svmono_xhtml (Failed)
367 - export/export/docbook/svmono_light_xhtml (Failed)
369 - export/export/docbook/svmult_xhtml (Failed)
1762 - export/export/xhtml/math_output_latex_docbook5 (Failed)
1866 - export/doc/EmbeddedObjects_xhtml (Failed)
1884 - export/doc/Formula-numbering_xhtml (Failed)
1956 - export/doc/Math_xhtml (Failed)
2015 - export/doc/UserGuide_xhtml (Failed)
2060 - export/doc/ar/UserGuide_xhtml (Failed)
2213 - export/doc/de/EmbeddedObjects_xhtml (Failed)
2231 - export/doc/de/Formelnummerierung_xhtml (Failed)
2267 - export/doc/de/Math_xhtml (Failed)
...


Where do I find the corresponding tests? I really know nothing about tests.

Also, does failing mean that there is a parsing error, or that the 
output is now different?


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Many xhtml/docbook tests now failing on master

2024-07-23 Thread Jean-Marc Lasgouttes


Le 23/07/2024 à 19:24, Kornel Benko a écrit :

Even with newest commits I get
71% tests passed, 132 tests failed out of 449
from
# ctest -R .xhtml

Kornel


Hopefully most of the issues are gone now. The biggest and stupidest 
problem was that a backup variable was a bool instead of an int. Neither 
the compiler nor the debugger have been useful to point this 
unfortunately. I spent a lot of time looking at code that seemed 
perfectly fine.


I we have some machinery to compare the result of exporting to DocBook 
before/after the patch would be good. The output is supposed to be 
exactly the same.


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[LyX/master] Fixup 216a6fb3: fix broken xml syntax

2024-07-23 Thread Jean-Marc Lasgouttes

commit a268fe096a58a7818554a7da4da85896bb289c81
Author: Jean-Marc Lasgouttes 
Date:   Tue Jul 23 15:04:49 2024 +0200

Fixup 216a6fb3: fix broken xml syntax

This commit addresses two issues:

1/ the embarassing one: the member SetMode::old_text_level_ was
   declared as bool instead of int. This means that is was definitely
   not a proper backup variable!

2/ a robustness issue: replace two consecutive test for isTest() by a
   boolean veriable that is used twice. This makes sure that 
   cannot be output without the corresponding .

Part of bug #13069.
---
 src/mathed/MathExtern.cpp | 6 --
 src/mathed/MathStream.h   | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/mathed/MathExtern.cpp b/src/mathed/MathExtern.cpp
index 1f9356f8f2..990d35e9d2 100644
--- a/src/mathed/MathExtern.cpp
+++ b/src/mathed/MathExtern.cpp
@@ -1646,11 +1646,13 @@ void mathmlize(MathData const & dat, MathMLStream & ms)
} else if (ar.size() == 1) {
ms << ar.front();
} else {
-   if (!ms.inText())
+   // protect against the value changing in the second test.
+   bool const intext = ms.inText();
+   if (!intext)
ms << MTag("mrow");
for (MathData::const_iterator it = ar.begin(); it != ar.end(); 
++it)
(*it)->mathmlize(ms);
-   if (!ms.inText())
+   if (!intext)
ms << ETag("mrow");
}
 }
diff --git a/src/mathed/MathStream.h b/src/mathed/MathStream.h
index a9edae08c0..40bb7d3bfb 100644
--- a/src/mathed/MathStream.h
+++ b/src/mathed/MathStream.h
@@ -469,7 +469,7 @@ private:
///
MathMLStream & ms_;
///
-   bool old_text_level_;
+   int old_text_level_;
 };
 
 
-- 
lyx-cvs mailing list
lyx-cvs@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-cvs

Re: Many xhtml/docbook tests now failing on master

2024-07-23 Thread Jean-Marc Lasgouttes


Le 23/07/2024 à 19:24, Kornel Benko a écrit :

Am Mon, 22 Jul 2024 16:47:14 -0400
schrieb Scott Kostyshak :


I don't have time to look into them but a whole bunch of xhtml and
docbook tests started failing recently on master. Kornel can you
reproduce?

Scott


Even with newest commits I get
71% tests passed, 132 tests failed out of 449
from
# ctest -R .xhtml


I have a patch in hand. Let write a proper commit message.

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[USN-6909-1] Bind vulnerabilities

2024-07-23 Thread Marc Deslauriers


==
Ubuntu Security Notice USN-6909-1
July 23, 2024

bind9 vulnerabilities
==

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 24.04 LTS
- Ubuntu 22.04 LTS
- Ubuntu 20.04 LTS

Summary:

Several security issues were fixed in Bind.

Software Description:
- bind9: Internet Domain Name Server

Details:

It was discovered that Bind incorrectly handled a flood of DNS messages
over TCP. A remote attacker could possibly use this issue to cause Bind to
become unstable, resulting in a denial of service. (CVE-2024-0760)

Toshifumi Sakaguchi discovered that Bind incorrectly handled having a very
large number of RRs existing at the same time. A remote attacker could
possibly use this issue to cause Bind to consume resources, leading to a
denial of service. (CVE-2024-1737)

It was discovered that Bind incorrectly handled a large number of SIG(0)
signed requests. A remote attacker could possibly use this issue to cause
Bind to consume resources, leading to a denial of service. (CVE-2024-1975)

Daniel Stränger discovered that Bind incorrectly handled serving both
stable cache data and authoritative zone content. A remote attacker could
possibly use this issue to cause Bind to crash, resulting in a denial of
service. (CVE-2024-4076)

On Ubuntu 20.04 LTS, Bind has been updated from 9.16 to 9.18. In addition
to security fixes, the updated packages contain bug fixes, new features,
and possibly incompatible changes.

Please see the following for more information:

https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918

Update instructions:

The problem can be corrected by updating your system to the following
package versions:

Ubuntu 24.04 LTS
  bind9   1:9.18.28-0ubuntu0.24.04.1

Ubuntu 22.04 LTS
  bind9   1:9.18.28-0ubuntu0.22.04.1

Ubuntu 20.04 LTS
  bind9   1:9.18.28-0ubuntu0.20.04.1

This update uses a new upstream release, which includes additional bug
fixes. In general, a standard system update will make all the necessary
changes.

References:
  https://ubuntu.com/security/notices/USN-6909-1
  CVE-2024-0760, CVE-2024-1737, CVE-2024-1975, CVE-2024-4076

Package Information:
  https://launchpad.net/ubuntu/+source/bind9/1:9.18.28-0ubuntu0.24.04.1
  https://launchpad.net/ubuntu/+source/bind9/1:9.18.28-0ubuntu0.22.04.1
  https://launchpad.net/ubuntu/+source/bind9/1:9.18.28-0ubuntu0.20.04.1



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Numbers in library names

2024-07-23 Thread Marc Nieper-Wißkirchen

Am Di., 23. Juli 2024 um 17:06 Uhr schrieb Lassi Kortela :

> > There are other costs involved, e.g., when mappings from library names
> > to the pathnames have to be specified. While it is straightforward to
> > encode a number of characters like "/" or ":", it is not so
> > straightforward to encode numbers differently from symbols that look
> > like numbers.
>
> Why would symbols and numbers be encoded differently? What practical
> benefits are conferred by keeping them different, and what practical
> harm comes from treating them as equivalent?
>

In R7RS, (srfi 1) and (srfi |1|) are different library names.


> >  > The last name part is the most specific one.
> >
> > What does that mean, and what are the ramifications?
> >
> > Intuitively and semantically, it makes more sense to derive the needed
> > lexical information from the most specific library name part than from a
> > generic top-level name part.
>
> Are the practical implications for Scheme programmers or implementers?
> It's the whole library name that is of interest. Any part ought not be
> interesting on its own.
>

Parts of Scheme forms can be interesting even if they do not make sense as
stand-alone identifiers.


> > Singular only insofar as Chez Scheme is the only affected implementation
> > that I know.  Ikarus was another existing implementation that may
> > support the Chez extensions as well as may any other implementation
> > whose expander is close enough to Chez's.
>
> Following the Chez lineage: Ikarus and Vicare are unlikely to have
> active users. Loko and Unsyntax are still young.
>

Your reply is out of context. We were talking about the creation of R7RS,
which happened more than ten years ago.


> The existing, widely used support for numerical library name parts in
> R7RS is a big deal. Successive editions of RnRS should not vacillate in
> order to make abstruse technical points. There has to be a serious
> blocker. I am willing to hear if there is, but the obstacles explained
> so far seem to me either trivial or outside the remit of RnRS.
>
> > Aesthetics matter when they are not mostly subjective.
>
> There is more variety in taste than I expected. Nevertheless, the fact
> is that there are two widespread existing conventions. We should make
> them interoperate.
>

I agree with the last point; a future RnRS can special-case "(srfi N)",
demanding that the library described by it must be the same as the library
"(srfi :N)".  The latter would be the default and numbers in library names
otherwise deprecated.  Numbers would be reserved for versioning.

Re: [PATCH v3 1/2] dt-bindings: display: bridge: add TI TDP158

2024-07-23 Thread Marc Gonzalez

On 27/06/2024 18:25, Conor Dooley wrote:

> On Thu, Jun 27, 2024 at 01:13:03PM +0200, Marc Gonzalez wrote:
>
>> TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver.
>> It supports DVI 1.0, HDMI 1.4b and 2.0b.
>> It supports 4 TMDS channels, HPD, and a DDC interface.
>> It supports dual power supply rails (1.1V on VDD, 3.3V on VCC)
>> for power reduction. Several methods of power management are
>> implemented to reduce overall power consumption.
>> It supports fixed receiver EQ gain using I2C or pin strap to
>> compensate for different lengths input cable or board traces.
>>
>> Features
>>
>> - AC-coupled TMDS or DisplayPort dual-mode physical layer input
>> to HDMI 2.0b TMDS physical layer output supporting up to 6Gbps
>> data rate, compatible with HDMI 2.0b electrical parameters
>> - DisplayPort dual-mode standard version 1.1
>> - Programmable fixed receiver equalizer up to 15.5dB
>> - Global or independent high speed lane control, pre-emphasis
>> and transmit swing, and slew rate control
>> - I2C or pin strap programmable
>> - Configurable as a DisplayPort redriver through I2C
>> - Full lane swap on main lanes
>> - Low power consumption (200 mW at 6Gbps, 8 mW in shutdown)
>>
>> https://www.ti.com/lit/ds/symlink/tdp158.pdf
>>
>> Signed-off-by: Marc Gonzalez 
>> ---
>>  .../bindings/display/bridge/ti,tdp158.yaml | 51 
>> ++
>>  1 file changed, 51 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tdp158.yaml 
>> b/Documentation/devicetree/bindings/display/bridge/ti,tdp158.yaml
>> new file mode 100644
>> index 0..21c8585c3bb2d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tdp158.yaml
>> @@ -0,0 +1,51 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/bridge/ti,tdp158.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TI TDP158 HDMI to TMDS Redriver
>> +
>> +maintainers:
>> +  - Arnaud Vrac 
>> +  - Pierre-Hugues Husson 
>> +
>> +properties:
>> +  compatible:
>> +const: ti,tdp158
>> +
>> +  reg:
>> +description: I2C address of the device
> 
> Is reg not required? How do you communicate with the device if the i2c
> bus is not connected? Is the enable GPIO enough to operate it in some
> situations?
> 
> Otherwise this looks good to me, but given Maxime commented about the
> complexity of the device, I'm probably out of my depth!

Hello Conor,

A cycle has been detected:
Above, you defer to Maxime.
Yet later, he wrote:
"DT maintainers have required that reg is always present"


I propose we NOT mark the "reg" property as required.
(Thus, keep the binding as proposed in v3.)

Rationale:

- The device can be statically configured by pin straps,
in which case it is NOT connected to an I2C bus.

- Even if the device IS connected to an I2C bus,
no I2C accesses are required if the default configuration
meets the ODM's needs.

Is that OK with you? Can I get your Amen?

Regards

Re: Are library names data or syntax?

2024-07-23 Thread Marc Nieper-Wißkirchen

Am Mo., 22. Juli 2024 um 20:47 Uhr schrieb Maxime Devos <
maximede...@telenet.be>:

> > [...]
>
> >
>
> >In what kind of situation might a library name be made up of identifiers
> (syntax objects) that might need to carry lexical information?
>
>
>
> As implied by the previous: never (in Guile, and probably most others).
>
>
>
> The only exception I can think of, is if:
>
>
>
> * ‘define-library’/’library’ is implemented as a macro (this is not part
> of RnRS, but AFAIK neither is it against the standard)
>
> * hence, you can define a module from within another module (might be
> situationally useful, but comes with new difficulties for module lookup)
>
> * there are multiple module namespaces
>
> * to determine which module namespace to put the module in,
> ‘define-library’ uses lexical information
>
> * in particular, it uses components of the name of the library for lexical
> information, even though there are other options like using the _*whole*_
> name (i.e., (foo bar) itself instead of ‘foo’ or ‘bar’).
>
>
>
> That’s a lot of ifs, and even then identifiers aren’t necessary, since
> (AFAIK) the name (foo bar) itself carries lexical information (not sure).
>
>
>
> I’ve been assuming that numbers (in syntax) (say, #'3) don’t carry lexical
> info, but since ‘syntax numbers’ carry file name+position information, it’s
> not much of a stretch to potentially also include lexical information, so
> perhaps numbers would work just fine too! (Implementation-dependent, but
> ‘multiple module namespaces’ and ‘define-library as a macro’ are also
> implementation-dependent.)
>

This would need a redefinition of what a syntax object is (see the R6RS).
In principle, this would be possible, but the result would be incompatible
with the R6RS. In R6RS, a macro transformer is allowed to output raw
numbers; this would not be allowed in a hypothetical Scheme version that
assumes that numbers necessarily carry a wrap (as identifiers do in the
R6RS).

Source location information is not mandatory information for the expander,
so this reasoning does not apply here.

Marc

Re: [PATCH v5 4/4] arm64: dts: qcom: add HDMI nodes for msm8998

2024-07-23 Thread Marc Gonzalez

On 23/07/2024 15:43, Konrad Dybcio wrote:

> On 23.07.2024 3:38 PM, Marc Gonzalez wrote:
>
>> On 23/07/2024 15:08, Konrad Dybcio wrote:
>>
>>> On 23.07.2024 2:57 PM, Marc Gonzalez wrote:
>>>
>>>> On 23/07/2024 13:45, Konrad Dybcio wrote:
>>>>
>>>>> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote:
>>>>>
>>>>>> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote:
>>>>>>
>>>>>>> On 16/07/2024 18:37, Dmitry Baryshkov wrote:
>>>>>>>
>>>>>>>> No, that's fine. It is the SMMU issue that Konrad has been asking you
>>>>>>>> to take a look at.
>>>>>>>
>>>>>>> Context:
>>>>>>>
>>>>>>> [4.911422] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>>>> SID=0x0
>>>>>>> [4.923353] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>>>> PLVL=1]
>>>>>>> [4.927893] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>>>> SID=0x0
>>>>>>> [4.941928] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>>>> PLVL=1]
>>>>>>> [4.944438] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>>>> SID=0x0
>>>>>>> [4.956013] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>>>> PLVL=1]
>>>>>>> [4.961055] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>>>> SID=0x0
>>>>>>> [4.974565] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>>>> PLVL=1]
>>>>>>> [4.977628] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>>>> SID=0x0
>>>>>>> [4.989670] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>>>> PLVL=1]
>>>>>>>
>>>>>>>
>>>>>>> As I mentioned, I don't think I've ever seen issues from cd0.iommu
>>>>>>> on my board.
>>>>>>
>>>>>> Interestingly enough, I can also see iommu errors during WiFi startup
>>>>>> / shutdown on msm8998 / miix630. This leads me to thinking that it
>>>>>> well might be that there is a missing quirk in the iommu driver.
>>>>>>
>>>>>>> I can test a reboot loop for a few hours, to see if anything shows up.
>>>>>>
>>>>>> Yes, please.
>>>>>
>>>>> Yeah I do trust you Marc that it actually works for you and I'm not
>>>>> gonna delay this series because of that, but please go ahead and
>>>>> reboot-loop your board
>>>>>
>>>>> 8998/660 is """famous""" for it's iommu problems
>>>>
>>>> [   20.501062] arm-smmu 16c.iommu: Unhandled context fault: fsr=0x402, 
>>>> iova=0x, fsynr=0x1, cbfrsynra=0x1900, cb=0
>>>>
>>>> I get the above warning pretty reliably.
>>>> I don't think it's related to the issue(s) you mentioned.
>>>> System just keeps plodding along.
>>>
>>> Yeah that one's "fine"
>>
>> I booted 40 times in a loop.
>>
>> `grep -a -i FSYNR console.logs` just returns the same 16c.iommu
>> "Unhandled context fault" message 76 times (as above).
>>
>> NB: I have maxcpus=1 set in bootargs.
>>
>> Could the iommu issue be a race condition, NOT triggered when code
>> runs with less parallelism?
> 
> No clue, can you try without maxcpus=1?

Same behavior without maxcpus=1

40 boots, no panics, no FSYNR other than 16c.iommu

> The thing will likely run slower (because reasons), but shouldn't
> explode

That makes sense!

- Hey, boot is slow. What can we do to make it slower?
- Well, just add a bunch of cores running in parallel, that will get the job 
done!

As a matter of fact, trying to boot to command-line with
maxcpus=1 causes the system to lock up & reboot.
I had to add a systemd script to enable some cores at init.
Some qcom daemon must be locking a core & expect progress
from another process.

Regards

Re: [PATCH v5 4/4] arm64: dts: qcom: add HDMI nodes for msm8998

2024-07-23 Thread Marc Gonzalez

On 23/07/2024 15:43, Konrad Dybcio wrote:

> On 23.07.2024 3:38 PM, Marc Gonzalez wrote:
>
>> On 23/07/2024 15:08, Konrad Dybcio wrote:
>>
>>> On 23.07.2024 2:57 PM, Marc Gonzalez wrote:
>>>
>>>> On 23/07/2024 13:45, Konrad Dybcio wrote:
>>>>
>>>>> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote:
>>>>>
>>>>>> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote:
>>>>>>
>>>>>>> On 16/07/2024 18:37, Dmitry Baryshkov wrote:
>>>>>>>
>>>>>>>> No, that's fine. It is the SMMU issue that Konrad has been asking you
>>>>>>>> to take a look at.
>>>>>>>
>>>>>>> Context:
>>>>>>>
>>>>>>> [4.911422] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>>>> SID=0x0
>>>>>>> [4.923353] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>>>> PLVL=1]
>>>>>>> [4.927893] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>>>> SID=0x0
>>>>>>> [4.941928] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>>>> PLVL=1]
>>>>>>> [4.944438] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>>>> SID=0x0
>>>>>>> [4.956013] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>>>> PLVL=1]
>>>>>>> [4.961055] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>>>> SID=0x0
>>>>>>> [4.974565] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>>>> PLVL=1]
>>>>>>> [4.977628] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>>>> SID=0x0
>>>>>>> [4.989670] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>>>> PLVL=1]
>>>>>>>
>>>>>>>
>>>>>>> As I mentioned, I don't think I've ever seen issues from cd0.iommu
>>>>>>> on my board.
>>>>>>
>>>>>> Interestingly enough, I can also see iommu errors during WiFi startup
>>>>>> / shutdown on msm8998 / miix630. This leads me to thinking that it
>>>>>> well might be that there is a missing quirk in the iommu driver.
>>>>>>
>>>>>>> I can test a reboot loop for a few hours, to see if anything shows up.
>>>>>>
>>>>>> Yes, please.
>>>>>
>>>>> Yeah I do trust you Marc that it actually works for you and I'm not
>>>>> gonna delay this series because of that, but please go ahead and
>>>>> reboot-loop your board
>>>>>
>>>>> 8998/660 is """famous""" for it's iommu problems
>>>>
>>>> [   20.501062] arm-smmu 16c.iommu: Unhandled context fault: fsr=0x402, 
>>>> iova=0x, fsynr=0x1, cbfrsynra=0x1900, cb=0
>>>>
>>>> I get the above warning pretty reliably.
>>>> I don't think it's related to the issue(s) you mentioned.
>>>> System just keeps plodding along.
>>>
>>> Yeah that one's "fine"
>>
>> I booted 40 times in a loop.
>>
>> `grep -a -i FSYNR console.logs` just returns the same 16c.iommu
>> "Unhandled context fault" message 76 times (as above).
>>
>> NB: I have maxcpus=1 set in bootargs.
>>
>> Could the iommu issue be a race condition, NOT triggered when code
>> runs with less parallelism?
> 
> No clue, can you try without maxcpus=1?

Same behavior without maxcpus=1

40 boots, no panics, no FSYNR other than 16c.iommu

> The thing will likely run slower (because reasons), but shouldn't
> explode

That makes sense!

- Hey, boot is slow. What can we do to make it slower?
- Well, just add a bunch of cores running in parallel, that will get the job 
done!

As a matter of fact, trying to boot to command-line with
maxcpus=1 causes the system to lock up & reboot.
I had to add a systemd script to enable some cores at init.
Some qcom daemon must be locking a core & expect progress
from another process.

Regards

Re: [PATCH v5 4/4] arm64: dts: qcom: add HDMI nodes for msm8998

2024-07-23 Thread Marc Gonzalez

On 23/07/2024 15:08, Konrad Dybcio wrote:

> On 23.07.2024 2:57 PM, Marc Gonzalez wrote:
>
>> On 23/07/2024 13:45, Konrad Dybcio wrote:
>>
>>> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote:
>>>
>>>> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote:
>>>>
>>>>> On 16/07/2024 18:37, Dmitry Baryshkov wrote:
>>>>>
>>>>>> No, that's fine. It is the SMMU issue that Konrad has been asking you
>>>>>> to take a look at.
>>>>>
>>>>> Context:
>>>>>
>>>>> [4.911422] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>> SID=0x0
>>>>> [4.923353] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>> PLVL=1]
>>>>> [4.927893] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>> SID=0x0
>>>>> [4.941928] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>> PLVL=1]
>>>>> [4.944438] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>> SID=0x0
>>>>> [4.956013] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>> PLVL=1]
>>>>> [4.961055] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>> SID=0x0
>>>>> [4.974565] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>> PLVL=1]
>>>>> [4.977628] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>> SID=0x0
>>>>> [4.989670] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>> PLVL=1]
>>>>>
>>>>>
>>>>> As I mentioned, I don't think I've ever seen issues from cd0.iommu
>>>>> on my board.
>>>>
>>>> Interestingly enough, I can also see iommu errors during WiFi startup
>>>> / shutdown on msm8998 / miix630. This leads me to thinking that it
>>>> well might be that there is a missing quirk in the iommu driver.
>>>>
>>>>> I can test a reboot loop for a few hours, to see if anything shows up.
>>>>
>>>> Yes, please.
>>>
>>> Yeah I do trust you Marc that it actually works for you and I'm not
>>> gonna delay this series because of that, but please go ahead and
>>> reboot-loop your board
>>>
>>> 8998/660 is """famous""" for it's iommu problems
>>
>> [   20.501062] arm-smmu 16c.iommu: Unhandled context fault: fsr=0x402, 
>> iova=0x, fsynr=0x1, cbfrsynra=0x1900, cb=0
>>
>> I get the above warning pretty reliably.
>> I don't think it's related to the issue(s) you mentioned.
>> System just keeps plodding along.
> 
> Yeah that one's "fine"

I booted 40 times in a loop.

`grep -a -i FSYNR console.logs` just returns the same 16c.iommu
"Unhandled context fault" message 76 times (as above).

NB: I have maxcpus=1 set in bootargs.

Could the iommu issue be a race condition, NOT triggered when code
runs with less parallelism?

Regards

Re: [PATCH v5 4/4] arm64: dts: qcom: add HDMI nodes for msm8998

2024-07-23 Thread Marc Gonzalez

On 23/07/2024 15:08, Konrad Dybcio wrote:

> On 23.07.2024 2:57 PM, Marc Gonzalez wrote:
>
>> On 23/07/2024 13:45, Konrad Dybcio wrote:
>>
>>> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote:
>>>
>>>> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote:
>>>>
>>>>> On 16/07/2024 18:37, Dmitry Baryshkov wrote:
>>>>>
>>>>>> No, that's fine. It is the SMMU issue that Konrad has been asking you
>>>>>> to take a look at.
>>>>>
>>>>> Context:
>>>>>
>>>>> [4.911422] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>> SID=0x0
>>>>> [4.923353] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>> PLVL=1]
>>>>> [4.927893] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>> SID=0x0
>>>>> [4.941928] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>> PLVL=1]
>>>>> [4.944438] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>> SID=0x0
>>>>> [4.956013] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>> PLVL=1]
>>>>> [4.961055] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>> SID=0x0
>>>>> [4.974565] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>> PLVL=1]
>>>>> [4.977628] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>>>> SID=0x0
>>>>> [4.989670] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>>>> PLVL=1]
>>>>>
>>>>>
>>>>> As I mentioned, I don't think I've ever seen issues from cd0.iommu
>>>>> on my board.
>>>>
>>>> Interestingly enough, I can also see iommu errors during WiFi startup
>>>> / shutdown on msm8998 / miix630. This leads me to thinking that it
>>>> well might be that there is a missing quirk in the iommu driver.
>>>>
>>>>> I can test a reboot loop for a few hours, to see if anything shows up.
>>>>
>>>> Yes, please.
>>>
>>> Yeah I do trust you Marc that it actually works for you and I'm not
>>> gonna delay this series because of that, but please go ahead and
>>> reboot-loop your board
>>>
>>> 8998/660 is """famous""" for it's iommu problems
>>
>> [   20.501062] arm-smmu 16c.iommu: Unhandled context fault: fsr=0x402, 
>> iova=0x, fsynr=0x1, cbfrsynra=0x1900, cb=0
>>
>> I get the above warning pretty reliably.
>> I don't think it's related to the issue(s) you mentioned.
>> System just keeps plodding along.
> 
> Yeah that one's "fine"

I booted 40 times in a loop.

`grep -a -i FSYNR console.logs` just returns the same 16c.iommu
"Unhandled context fault" message 76 times (as above).

NB: I have maxcpus=1 set in bootargs.

Could the iommu issue be a race condition, NOT triggered when code
runs with less parallelism?

Regards

Re: [PATCH v5 4/4] arm64: dts: qcom: add HDMI nodes for msm8998

2024-07-23 Thread Marc Gonzalez

On 23/07/2024 13:45, Konrad Dybcio wrote:

> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote:
> 
>> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote:
>>
>>> On 16/07/2024 18:37, Dmitry Baryshkov wrote:
>>>
>>>> No, that's fine. It is the SMMU issue that Konrad has been asking you
>>>> to take a look at.
>>>
>>> Context:
>>>
>>> [4.911422] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>> SID=0x0
>>> [4.923353] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>> PLVL=1]
>>> [4.927893] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>> SID=0x0
>>> [4.941928] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>> PLVL=1]
>>> [4.944438] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>> SID=0x0
>>> [4.956013] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>> PLVL=1]
>>> [4.961055] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>> SID=0x0
>>> [4.974565] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>> PLVL=1]
>>> [4.977628] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>> SID=0x0
>>> [4.989670] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>> PLVL=1]
>>>
>>>
>>> As I mentioned, I don't think I've ever seen issues from cd0.iommu
>>> on my board.
>>
>> Interestingly enough, I can also see iommu errors during WiFi startup
>> / shutdown on msm8998 / miix630. This leads me to thinking that it
>> well might be that there is a missing quirk in the iommu driver.
>>
>>> I can test a reboot loop for a few hours, to see if anything shows up.
>>
>> Yes, please.
> 
> Yeah I do trust you Marc that it actually works for you and I'm not
> gonna delay this series because of that, but please go ahead and
> reboot-loop your board
> 
> 8998/660 is """famous""" for it's iommu problems

[   20.501062] arm-smmu 16c.iommu: Unhandled context fault: fsr=0x402, 
iova=0x, fsynr=0x1, cbfrsynra=0x1900, cb=0

I get the above warning pretty reliably.
I don't think it's related to the issue(s) you mentioned.
System just keeps plodding along.

Regards

Re: [PATCH v5 4/4] arm64: dts: qcom: add HDMI nodes for msm8998

2024-07-23 Thread Marc Gonzalez

On 23/07/2024 13:45, Konrad Dybcio wrote:

> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote:
> 
>> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote:
>>
>>> On 16/07/2024 18:37, Dmitry Baryshkov wrote:
>>>
>>>> No, that's fine. It is the SMMU issue that Konrad has been asking you
>>>> to take a look at.
>>>
>>> Context:
>>>
>>> [4.911422] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>> SID=0x0
>>> [4.923353] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>> PLVL=1]
>>> [4.927893] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>> SID=0x0
>>> [4.941928] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>> PLVL=1]
>>> [4.944438] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>> SID=0x0
>>> [4.956013] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>> PLVL=1]
>>> [4.961055] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>> SID=0x0
>>> [4.974565] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>> PLVL=1]
>>> [4.977628] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], 
>>> SID=0x0
>>> [4.989670] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU 
>>> PLVL=1]
>>>
>>>
>>> As I mentioned, I don't think I've ever seen issues from cd0.iommu
>>> on my board.
>>
>> Interestingly enough, I can also see iommu errors during WiFi startup
>> / shutdown on msm8998 / miix630. This leads me to thinking that it
>> well might be that there is a missing quirk in the iommu driver.
>>
>>> I can test a reboot loop for a few hours, to see if anything shows up.
>>
>> Yes, please.
> 
> Yeah I do trust you Marc that it actually works for you and I'm not
> gonna delay this series because of that, but please go ahead and
> reboot-loop your board
> 
> 8998/660 is """famous""" for it's iommu problems

[   20.501062] arm-smmu 16c.iommu: Unhandled context fault: fsr=0x402, 
iova=0x, fsynr=0x1, cbfrsynra=0x1900, cb=0

I get the above warning pretty reliably.
I don't think it's related to the issue(s) you mentioned.
System just keeps plodding along.

Regards

Re: [PATCH] meson: build chardev trace files when have_block

2024-07-23 Thread Marc-André Lureau

On Tue, Jul 23, 2024 at 2:35 PM Daniel P. Berrangé 
wrote:

> The QSD depends on chardev code, and is built when have_tools is
> true. This means conditionalizing chardev trace on have_system
> is wrong, we need have_block which is set have_system || have_tools.
>
> This latent bug was historically harmless because only the spice
> chardev included tracing, which wasn't built in a !have_system
> scenario.
>
> Signed-off-by: Daniel P. Berrangé 
>

Reviewed-by: Marc-André Lureau 


> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> This is an add-on needed for:
>
>   https://lists.nongnu.org/archive/html/qemu-devel/2024-07/msg05068.html
>
> since I discovered a tools-only build fails
>
> diff --git a/meson.build b/meson.build
> index a1e51277b0..d3850a8c0f 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -3327,6 +3327,7 @@ if have_block
>trace_events_subdirs += [
>  'authz',
>  'block',
> +'chardev',
>  'io',
>  'nbd',
>  'scsi',
> @@ -3338,7 +3339,6 @@ if have_system
>  'audio',
>  'backends',
>  'backends/tpm',
> -'chardev',
>  'ebpf',
>  'hw/9pfs',
>  'hw/acpi',
> --
> 2.45.2
>
>

[frameworks-kidletime] [Bug 328987] Power saving should not trigger if joystick/controller/gamepad is in use

2024-07-23 Thread Marc Cousin

https://bugs.kde.org/show_bug.cgi?id=328987

Marc Cousin  changed:

   What|Removed |Added

 CC||cousinm...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [PATCH v5 4/4] arm64: dts: qcom: add HDMI nodes for msm8998

2024-07-23 Thread Marc Gonzalez

On 16/07/2024 18:37, Dmitry Baryshkov wrote:

> No, that's fine. It is the SMMU issue that Konrad has been asking you
> to take a look at.

Context:

[4.911422] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], SID=0x0
[4.923353] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU PLVL=1]
[4.927893] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], SID=0x0
[4.941928] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU PLVL=1]
[4.944438] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], SID=0x0
[4.956013] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU PLVL=1]
[4.961055] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], SID=0x0
[4.974565] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU PLVL=1]
[4.977628] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], SID=0x0
[4.989670] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU PLVL=1]


As I mentioned, I don't think I've ever seen issues from cd0.iommu
on my board.

I can test a reboot loop for a few hours, to see if anything shows up.

Regards

Re: [PATCH v5 4/4] arm64: dts: qcom: add HDMI nodes for msm8998

2024-07-23 Thread Marc Gonzalez

On 16/07/2024 18:37, Dmitry Baryshkov wrote:

> No, that's fine. It is the SMMU issue that Konrad has been asking you
> to take a look at.

Context:

[4.911422] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], SID=0x0
[4.923353] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU PLVL=1]
[4.927893] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], SID=0x0
[4.941928] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU PLVL=1]
[4.944438] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], SID=0x0
[4.956013] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU PLVL=1]
[4.961055] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], SID=0x0
[4.974565] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU PLVL=1]
[4.977628] arm-smmu cd0.iommu: FSR= 0402 [Format=2 TF], SID=0x0
[4.989670] arm-smmu cd0.iommu: FSYNR0 = 0021 [S1CBNDX=0 PNU PLVL=1]


As I mentioned, I don't think I've ever seen issues from cd0.iommu
on my board.

I can test a reboot loop for a few hours, to see if anything shows up.

Regards

Re: [PATCH v4] osdep: add a qemu_close_all_open_fd() helper

2024-07-23 Thread Marc-André Lureau

Hi

On Wed, Jul 17, 2024 at 4:48 PM Clément Léger  wrote:

> Since commit 03e471c41d8b ("qemu_init: increase NOFILE soft limit on
> POSIX"), the maximum number of file descriptors that can be opened are
> raised to nofile.rlim_max. On recent debian distro, this yield a maximum
> of 1073741816 file descriptors. Now, when forking to start
> qemu-bridge-helper, this actually calls close() on the full possible file
> descriptor range (more precisely [3 - sysconf(_SC_OPEN_MAX)]) which
> takes a considerable amount of time. In order to reduce that time,
> factorize existing code to close all open files descriptors in a new
> qemu_close_all_open_fd() function. This function uses various methods
> to close all the open file descriptors ranging from the most efficient
> one to the least one. It also accepts an ordered array of file
> descriptors that should not be closed since this is required by the
> callers that calls it after forking.
>
> Signed-off-by: Clément Léger 
> Reviewed-by: Richard Henderson 
>


GLib already implemented those kinds of portable facilities.

I wonder why launch_script() is not using glib gspawn API.

async-teardown should use g_clownfrom() when glib >= 2.80.

my 2c

-- 
Marc-André Lureau

Re: Many xhtml/docbook tests now failing on master

2024-07-22 Thread Jean-Marc Lasgouttes


Le 22/07/2024 à 23:58, Scott Kostyshak a écrit :

On Mon, Jul 22, 2024 at 11:27:46PM GMT, Jean-Marc Lasgouttes wrote:

Le 22/07/2024 à 22:47, Scott Kostyshak a écrit :

I don't have time to look into them but a whole bunch of xhtml and
docbook tests started failing recently on master. Kornel can you
reproduce?


I would be grateful to have individual examples. I guess the point made by
Enrico is one of those issues.


One example is doc/Tutorial

The first few errors in the test logs are the following. Can you reproduce 
these with xmllint?


Excellent example. Yes I can reproduce. Let's see what I can do about it.

JMarc

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/2.4.x] Cleanup MathMLStream

2024-07-22 Thread Jean-Marc Lasgouttes


Le 22/07/2024 à 22:40, Enrico Forestieri a écrit :

diff --git a/src/mathed/InsetMathChar.cpp b/src/mathed/InsetMathChar.cpp
index 199982a5f7..82d0b63f1e 100644
--- a/src/mathed/InsetMathChar.cpp
+++ b/src/mathed/InsetMathChar.cpp
@@ -248,7 +248,7 @@ void InsetMathChar::mathmlize(MathMLStream & ms) 
const


if (ms.inText()) {
    if (entity.empty())
-    ms.os().put(char_);
+    ms << char_;
    else
    ms << from_ascii(entity);
    return;


Note that this operator is like

 MathMLStream & operator<<(MathMLStream & ms, char_type c)
 {
-   ms.os().put(c);
+   ms << docstring(1,c);
return ms;
 }

Is it wrong? Is it better to use put() like it was?

JMarc


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/2.4.x] Cleanup MathMLStream

2024-07-22 Thread Jean-Marc Lasgouttes


Le 22/07/2024 à 22:40, Enrico Forestieri a écrit :
I don't understand the need for the two changes above. Note that on 
systems where sizeof(wchar_t) == 2, lyx::char_type is defined as a 32- 
bit value. So, with the above changes, char_ will be output as a number 
rather than a character.


What are typically those systems? I can introduce a MathML::put(c) 
method. It is important that everything goes through MathML so that we 
can add out hooks here. Direct access to underlying stream is not good.


Currently (not my doing), MathStream has the operators
MathMLStream & operator<<(MathMLStream &, char);
MathMLStream & operator<<(MathMLStream &, char_type);

Do you mean that these two should go and be replaced by put() methods? 
What is the portable solution?


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Many xhtml/docbook tests now failing on master

2024-07-22 Thread Jean-Marc Lasgouttes


Le 22/07/2024 à 22:47, Scott Kostyshak a écrit :

I don't have time to look into them but a whole bunch of xhtml and
docbook tests started failing recently on master. Kornel can you
reproduce?


I would be grateful to have individual examples. I guess the point made 
by Enrico is one of those issues.


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Are library names data or syntax?

2024-07-22 Thread Marc Nieper-Wißkirchen

Arne, you may want to take a look at Chez's "module" syntax, see [1]. It is
orthogonal to our discussion about library names, but it may be what you
have in mind for your specific use case. A module is like a library but is
bound to an identifier, not to a library name.

Marc

--

[1] https://cisco.github.io/ChezScheme/csug10.0/syntax.html#./syntax:h5

Am Mo., 22. Juli 2024 um 23:05 Uhr schrieb Dr. Arne Babenhauserheide <
arne_...@web.de>:

> Maxime Devos  writes:
> > * hence, you can define a module from within another module (might be
> > situationally useful, but comes with new difficulties for module
> > lookup)
>
> I actually tried something in that direction in enter three witches —
> and failed.
>
> I wanted to add a macro that maps
>
> SCENE I
>
> to defining a module that cleanly separates different parts of a story.
>
> But I didn’t get that to work well (because it would have had to add
> automatic exports and canonical imports and all together caused more
> problems than it solved.
>
> Or maybe I didn’t understand well enough what I was doing. Generating
> code that generates modules isn’t a good idea if there’s a similar
> option that uses standard mechanisms.
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein,
> ohne es zu merken.
> draketo.de
>

Re: Numbers in library names

2024-07-22 Thread Marc Nieper-Wißkirchen

Am Mo., 22. Juli 2024 um 20:13 Uhr schrieb Lassi Kortela :

> > As I wrote, this is a syntactic extension of Chez Scheme - but a very
> > useful one - and outside of the R6RS.  The Unsyntax expander I wrote
> > also implements it.
>
> If patching these two implementations to use the first library name part
> instead of the last is the only technical obstacle to numbers in library
> names, it seems the cost is trivial.
>

There are other costs involved, e.g., when mappings from library names to
the pathnames have to be specified. While it is straightforward to encode a
number of characters like "/" or ":", it is not so straightforward to
encode numbers differently from symbols that look like numbers.


> > Why not take the first library name part instead of the last?
> >
> > The last name part is the most specific one.
>
> What does that mean, and what are the ramifications?
>

Intuitively and semantically, it makes more sense to derive the needed
lexical information from the most specific library name part than from a
generic top-level name part.


> > the R7RS authors were
> > likely unaware of the incompatibility of their proposal to allow numeric
> > name parts with existing implementations and language extensions.
>
> Implementation, singular.
>

Singular only insofar as Chez Scheme is the only affected implementation
that I know.  Ikarus was another existing implementation that may support
the Chez extensions as well as may any other implementation whose expander
is close enough to Chez's.


> > I don't buy that numeric library parts are particularly useful; they are
> > just one option. The SRFI 97 convention works as well as the SRFI-0
> > convention of "srfi-N" names, which is basically also used by Guile.
>
> Aesthetics matter.
>

Aesthetics matter when they are not mostly subjective.

Re: Numbers in library names

2024-07-22 Thread Marc Nieper-Wißkirchen

Am Mo., 22. Juli 2024 um 22:52 Uhr schrieb Artyom Bologov :

> Hi y'all,
>
> I've been confused by the statements that R6/7RS don't have numbers in
> library names. Because both kinda do.
>
> R6RS seems to allow the last library name element to be a list (?) of
> numbers explicitly reserved for library version:
> See https://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html
>
> R7RS doesn't specify the meaning of integers, but it allows them too:
> >  is a list whose members are identifiers and exact
> non-negative integers.
>
> https://standards.scheme.org/corrected-r7rs/r7rs-Z-H-7.html#TAG:__tex2page_sec_5.6.1
>
> Am I missing something?
>

The library version of R6RS is not part of the library name. An R6RS system
SHOULD not allow two library implementations with the same name but with
different versions to be loaded at the same time.  In contrast, in R7RS, a
number can be an ordinary part of a library name while it does not support
library versioning.

Does this help?

Your confusion is understandable and supports my earlier guess that R6RS
also disallows numbers in library names because it leads to, well,
confusion with the version numbers.

Marc

[LyX/2.4.x] Fix crash when generating MathML with InsetMathBox

2024-07-22 Thread Jean-Marc Lasgouttes

commit b29b3eb1fcbc30aad3c5e2800a9db61b823f65ae
Author: Jean-Marc Lasgouttes 
Date:   Sat Jul 20 12:15:32 2024 +0200

Fix crash when generating MathML with InsetMathBox

Instead of generating code and parsing it to add ... at
the right spots, this commit honors the text mode setting that was
already present in the codebase to generate it automatically.

This is the work of two helper methods in MathMLStream:

* beforeText() notices when the stream is in text mode and that a
   has not yet been generated. In this case it inserts it, so
  that raw text can be emitted afterwards.

* beforeTag() checks whether a  needs to be closed at this
  point, and does it if needed.

To make this work, the code now tracks the nesting level in the
stream, and compares it the what the level was when text mode has been
enabled using the SetMode helper function.

In order to avoid later bugs, member os() that allows to access the
underlying stream of MathMLStream is removed. This required many <<
operators to become friends of MathMLStream.

In InsetMathBox, rename splitAndWrapInMText() to mathmlizeHelper(),
which is not just a method that sets text mode inside a 
element.

In InsetMathFont and InsetMathHull, the explicit generation of nesting
in ... can be removed now.

Fixes bug #13069.

(cherry picked from commit 216a6fb348dedac3230f651287a0ccfb48b88818)
---
 src/mathed/InsetMath.cpp |  5 ++-
 src/mathed/InsetMathBox.cpp  | 74 +++-
 src/mathed/InsetMathFont.cpp |  2 --
 src/mathed/InsetMathHull.cpp |  6 ++--
 src/mathed/MathStream.cpp| 64 --
 src/mathed/MathStream.h  | 27 +++-
 status.24x   |  7 +++--
 7 files changed, 93 insertions(+), 92 deletions(-)

diff --git a/src/mathed/InsetMath.cpp b/src/mathed/InsetMath.cpp
index 5aea5716ce..5dee0c31ba 100644
--- a/src/mathed/InsetMath.cpp
+++ b/src/mathed/InsetMath.cpp
@@ -204,10 +204,13 @@ void InsetMath::mathematica(MathematicaStream & os) const
 
 void InsetMath::mathmlize(MathMLStream & ms) const
 {
+   SetMode rawmode(ms, false);
ms << "";
ms << MTagInline("mi");
-   NormalStream ns(ms.os());
+   odocstringstream ods;
+   NormalStream ns(ods);
normalize(ns);
+   ms << ods.str();
ms << ETagInline("mi");
 }
 
diff --git a/src/mathed/InsetMathBox.cpp b/src/mathed/InsetMathBox.cpp
index 6feddf9cdd..f06ffcf95d 100644
--- a/src/mathed/InsetMathBox.cpp
+++ b/src/mathed/InsetMathBox.cpp
@@ -59,69 +59,19 @@ void InsetMathBox::normalize(NormalStream & os) const
 
 
 namespace {
-void splitAndWrapInMText(MathMLStream & ms, MathData const & cell,
-const std::string & attributes)
+// Generate the MathML, making sure that anything that is outside of
+// any tag is wrapped in  tags, then wrap the whole thing in an
+//  tag with attributes
+void mathmlizeHelper(MathMLStream & ms, MathData const & cell, const 
std::string & attributes)
 {
-   // First, generate the inset into a string of its own.
-   docstring inset_contents;
-   {
-   odocstringstream ostmp;
-   MathMLStream mstmp(ostmp, ms.xmlns());
-
-   SetMode textmode(mstmp, true);
-   mstmp << cell;
-
-   inset_contents = ostmp.str();
-   }
-
-   // No tags are allowed within : split the string if there are 
tags.
-   std::vector parts;
-   while (true) {
-   std::size_t angle_pos = inset_contents.find('<');
-   if (angle_pos == docstring::npos)
-   break;
-
-   // String structure:
-   // - prefix: pure text, no tag
-   // - tag to split: something like 1 or more 
complicated
-   //   (like nested tags), with or without name space
-   // - rest to be taken care of in the next iteration
-
-   // Push the part before the tag.
-   parts.emplace_back(inset_contents.substr(0, angle_pos));
-   inset_contents = inset_contents.substr(angle_pos);
-   // Now, inset_contents starts with the tag to isolate, so that
-   // inset_contents[0] == '<'
-
-   // Push the tag, up to its end. Process: find the tag name 
(either
-   // before > or the first attribute of the tag), then the 
matching end
-   // tag, then proceed with pushing.
-   const std::size_t tag_name_end =
-   std::min(inset_contents.find(' ', 1), 
inset_contents.find('>', 1));
-   const std::size_t tag_name_length =

[LyX/2.4.x] Cleanup MathMLStream

2024-07-22 Thread Jean-Marc Lasgouttes

commit 17bc6d05b327034c2034087978c2ebf9f8d9e469
Author: Jean-Marc Lasgouttes 
Date:   Fri Jul 19 14:57:58 2024 +0200

Cleanup MathMLStream

This is preparatory work for fixing ticket #13069.

Remove direct accesses to the underlying stream of MathMLStream in
InsetMathChar, InsetMathSpecialChar, and in all << operators other
than MathMLStream << docstring. This will allow to add a hook later in
this operator.

Move default values of MathMLStream private members to their definition.

Get rid of line_ member, which is not used.

(cherry picked from commit fbd4b0a13fae4263cc88aa76bc4fbba5178b15fa)
---
 src/mathed/InsetMathChar.cpp|  2 +-
 src/mathed/InsetMathSpecialChar.cpp |  2 +-
 src/mathed/MathStream.cpp   | 22 +++---
 src/mathed/MathStream.h | 16 +---
 4 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/src/mathed/InsetMathChar.cpp b/src/mathed/InsetMathChar.cpp
index 199982a5f7..82d0b63f1e 100644
--- a/src/mathed/InsetMathChar.cpp
+++ b/src/mathed/InsetMathChar.cpp
@@ -248,7 +248,7 @@ void InsetMathChar::mathmlize(MathMLStream & ms) const
 
if (ms.inText()) {
if (entity.empty())
-   ms.os().put(char_);
+   ms << char_;
else
ms << from_ascii(entity);
return;
diff --git a/src/mathed/InsetMathSpecialChar.cpp 
b/src/mathed/InsetMathSpecialChar.cpp
index 746cec5bda..12c9a4c111 100644
--- a/src/mathed/InsetMathSpecialChar.cpp
+++ b/src/mathed/InsetMathSpecialChar.cpp
@@ -139,7 +139,7 @@ void InsetMathSpecialChar::mathmlize(MathMLStream & ms) 
const
ms << "&";
break;
default:
-   ms.os().put(char_);
+   ms << char_;
break;
}
 }
diff --git a/src/mathed/MathStream.cpp b/src/mathed/MathStream.cpp
index 4a006e4809..dc4aa05df9 100644
--- a/src/mathed/MathStream.cpp
+++ b/src/mathed/MathStream.cpp
@@ -289,7 +289,7 @@ TeXMathStream & operator<<(TeXMathStream & ws, unsigned int 
i)
 
 
 MathMLStream::MathMLStream(odocstream & os, std::string const & xmlns)
-   : os_(os), tab_(0), line_(0), in_text_(false), xmlns_(xmlns)
+   : os_(os), xmlns_(xmlns)
 {
if (in_text_)
font_math_style_ = TEXT_STYLE;
@@ -338,23 +338,30 @@ MathMLStream & operator<<(MathMLStream & ms, MathData 
const & ar)
 }
 
 
-MathMLStream & operator<<(MathMLStream & ms, char const * s)
+MathMLStream & operator<<(MathMLStream & ms, docstring const & s)
 {
ms.os() << s;
return ms;
 }
 
 
+MathMLStream & operator<<(MathMLStream & ms, char const * s)
+{
+   ms << from_utf8(s);
+   return ms;
+}
+
+
 MathMLStream & operator<<(MathMLStream & ms, char c)
 {
-   ms.os() << c;
+   ms << docstring(1,c);
return ms;
 }
 
 
 MathMLStream & operator<<(MathMLStream & ms, char_type c)
 {
-   ms.os().put(c);
+   ms << docstring(1,c);
return ms;
 }
 
@@ -410,13 +417,6 @@ MathMLStream & operator<<(MathMLStream & ms, CTag const & 
t)
 }
 
 
-MathMLStream & operator<<(MathMLStream & ms, docstring const & s)
-{
-   ms.os() << s;
-   return ms;
-}
-
-
 //
 
 
diff --git a/src/mathed/MathStream.h b/src/mathed/MathStream.h
index ca7543101f..f46c9878ef 100644
--- a/src/mathed/MathStream.h
+++ b/src/mathed/MathStream.h
@@ -9,8 +9,8 @@
  * Full author contact details are available in file CREDITS.
  */
 
-#ifndef MATH_MATHMLSTREAM_H
-#define MATH_MATHMLSTREAM_H
+#ifndef MATH_MATHSTREAM_H
+#define MATH_MATHSTREAM_H
 
 #include "InsetMath.h"
 #include "FontInfo.h"
@@ -382,13 +382,9 @@ public:
void cr();
///
odocstream & os() { return os_; }
-   ///
-   int line() const { return line_; }
-   ///
+   /// Indentation when nesting tags
int & tab() { return tab_; }
///
-   friend MathMLStream & operator<<(MathMLStream &, char const *);
-   ///
void defer(docstring const &);
///
void defer(std::string const &);
@@ -412,11 +408,9 @@ private:
///
odocstream & os_;
///
-   int tab_;
-   ///
-   int line_;
+   int tab_ = 0;
///
-   bool in_text_;
+   bool in_text_ = false;
///
odocstringstream deferred_;
///
-- 
lyx-cvs mailing list
lyx-cvs@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-cvs

[LyX/master] Make scrolling-by-selection smoother

2024-07-22 Thread Jean-Marc Lasgouttes

commit 1cc1f0ba27d1846ba244507529d4795ecfa29a39
Author: Jean-Marc Lasgouttes 
Date:   Sat Jul 20 19:47:32 2024 +0200

Make scrolling-by-selection smoother

This trivial patch makes scrolling-by-selection smoother by dividing
the step size and the time between steps by 8 when generating
synthetic events in work area.

The scrolling speed is unchanged, but the result is visually better.
---
 src/frontends/qt/GuiWorkArea.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/frontends/qt/GuiWorkArea.cpp b/src/frontends/qt/GuiWorkArea.cpp
index 462fabda1e..4dfd365d79 100644
--- a/src/frontends/qt/GuiWorkArea.cpp
+++ b/src/frontends/qt/GuiWorkArea.cpp
@@ -943,6 +943,8 @@ void GuiWorkArea::generateSyntheticMouseEvent()
step = 8 / (time * time);
time = 40;
}
+   step /= 8;
+   time /= 8;
}
d->synthetic_mouse_event_.timeout.setTimeout(time);
d->synthetic_mouse_event_.timeout.start();
-- 
lyx-cvs mailing list
lyx-cvs@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-cvs

Re: [RFC] Make scrolling-by-selection smoother

2024-07-22 Thread Jean-Marc Lasgouttes


Le 22/07/2024 à 21:49, Pavel Sanda a écrit :

On Sat, Jul 20, 2024 at 09:22:02PM +0200, Jean-Marc Lasgouttes wrote:

So, especially if you have a slow-ish computer, please test.


I tested on two archaic laptops and do not see any visible difference
in speed. But the version with your patch is aesthetically way better.


Thanks for testing. The speed is supposed to be the same indeed, but 
there are more smaller scroll events. I will push this version and we'll 
see whether we want to tweak it.


I am glad the performance is good enough in any case.


We could perhaps make the selection down little bit faster in full-screen mode,
but that's irrelevant wrt your patch.


Indeed in full screen the mouse cannot be below the window. I do not 
know how to handle that.


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[LyX/master] Fix crash when generating MathML with InsetMathBox

2024-07-22 Thread Jean-Marc Lasgouttes

commit 216a6fb348dedac3230f651287a0ccfb48b88818
Author: Jean-Marc Lasgouttes 
Date:   Sat Jul 20 12:15:32 2024 +0200

Fix crash when generating MathML with InsetMathBox

Instead of generating code and parsing it to add ... at
the right spots, this commit honors the text mode setting that was
already present in the codebase to generate it automatically.

This is the work of two helper methods in MathMLStream:

* beforeText() notices when the stream is in text mode and that a
   has not yet been generated. In this case it inserts it, so
  that raw text can be emitted afterwards.

* beforeTag() checks whether a  needs to be closed at this
  point, and does it if needed.

To make this work, the code now tracks the nesting level in the
stream, and compares it the what the level was when text mode has been
enabled using the SetMode helper function.

In order to avoid later bugs, member os() that allows to access the
underlying stream of MathMLStream is removed. This required many <<
operators to become friends of MathMLStream.

In InsetMathBox, rename splitAndWrapInMText() to mathmlizeHelper(),
which is not just a method that sets text mode inside a 
element.

In InsetMathFont and InsetMathHull, the explicit generation of nesting
in ... can be removed now.

Fixes bug #13069.
---
 src/mathed/InsetMath.cpp |  5 ++-
 src/mathed/InsetMathBox.cpp  | 74 +++-
 src/mathed/InsetMathFont.cpp |  2 --
 src/mathed/InsetMathHull.cpp |  6 ++--
 src/mathed/MathStream.cpp| 64 --
 src/mathed/MathStream.h  | 27 +++-
 6 files changed, 88 insertions(+), 90 deletions(-)

diff --git a/src/mathed/InsetMath.cpp b/src/mathed/InsetMath.cpp
index 5aea5716ce..5dee0c31ba 100644
--- a/src/mathed/InsetMath.cpp
+++ b/src/mathed/InsetMath.cpp
@@ -204,10 +204,13 @@ void InsetMath::mathematica(MathematicaStream & os) const
 
 void InsetMath::mathmlize(MathMLStream & ms) const
 {
+   SetMode rawmode(ms, false);
ms << "";
ms << MTagInline("mi");
-   NormalStream ns(ms.os());
+   odocstringstream ods;
+   NormalStream ns(ods);
normalize(ns);
+   ms << ods.str();
ms << ETagInline("mi");
 }
 
diff --git a/src/mathed/InsetMathBox.cpp b/src/mathed/InsetMathBox.cpp
index 6feddf9cdd..f06ffcf95d 100644
--- a/src/mathed/InsetMathBox.cpp
+++ b/src/mathed/InsetMathBox.cpp
@@ -59,69 +59,19 @@ void InsetMathBox::normalize(NormalStream & os) const
 
 
 namespace {
-void splitAndWrapInMText(MathMLStream & ms, MathData const & cell,
-const std::string & attributes)
+// Generate the MathML, making sure that anything that is outside of
+// any tag is wrapped in  tags, then wrap the whole thing in an
+//  tag with attributes
+void mathmlizeHelper(MathMLStream & ms, MathData const & cell, const 
std::string & attributes)
 {
-   // First, generate the inset into a string of its own.
-   docstring inset_contents;
-   {
-   odocstringstream ostmp;
-   MathMLStream mstmp(ostmp, ms.xmlns());
-
-   SetMode textmode(mstmp, true);
-   mstmp << cell;
-
-   inset_contents = ostmp.str();
-   }
-
-   // No tags are allowed within : split the string if there are 
tags.
-   std::vector parts;
-   while (true) {
-   std::size_t angle_pos = inset_contents.find('<');
-   if (angle_pos == docstring::npos)
-   break;
-
-   // String structure:
-   // - prefix: pure text, no tag
-   // - tag to split: something like 1 or more 
complicated
-   //   (like nested tags), with or without name space
-   // - rest to be taken care of in the next iteration
-
-   // Push the part before the tag.
-   parts.emplace_back(inset_contents.substr(0, angle_pos));
-   inset_contents = inset_contents.substr(angle_pos);
-   // Now, inset_contents starts with the tag to isolate, so that
-   // inset_contents[0] == '<'
-
-   // Push the tag, up to its end. Process: find the tag name 
(either
-   // before > or the first attribute of the tag), then the 
matching end
-   // tag, then proceed with pushing.
-   const std::size_t tag_name_end =
-   std::min(inset_contents.find(' ', 1), 
inset_contents.find('>', 1));
-   const std::size_t tag_name_length = tag_name_end - 1;
-   const docstring tag_name = inset_contents.substr(1, 
tag_name_length);
-
-   const std::size_t end_ta

[LyX/master] Cleanup MathMLStream

2024-07-22 Thread Jean-Marc Lasgouttes

commit fbd4b0a13fae4263cc88aa76bc4fbba5178b15fa
Author: Jean-Marc Lasgouttes 
Date:   Fri Jul 19 14:57:58 2024 +0200

Cleanup MathMLStream

This is preparatory work for fixing ticket #13069.

Remove direct accesses to the underlying stream of MathMLStream in
InsetMathChar, InsetMathSpecialChar, and in all << operators other
than MathMLStream << docstring. This will allow to add a hook later in
this operator.

Move default values of MathMLStream private members to their definition.

Get rid of line_ member, which is not used.
---
 src/mathed/InsetMathChar.cpp|  2 +-
 src/mathed/InsetMathSpecialChar.cpp |  2 +-
 src/mathed/MathStream.cpp   | 22 +++---
 src/mathed/MathStream.h | 16 +---
 4 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/src/mathed/InsetMathChar.cpp b/src/mathed/InsetMathChar.cpp
index 199982a5f7..82d0b63f1e 100644
--- a/src/mathed/InsetMathChar.cpp
+++ b/src/mathed/InsetMathChar.cpp
@@ -248,7 +248,7 @@ void InsetMathChar::mathmlize(MathMLStream & ms) const
 
if (ms.inText()) {
if (entity.empty())
-   ms.os().put(char_);
+   ms << char_;
else
ms << from_ascii(entity);
return;
diff --git a/src/mathed/InsetMathSpecialChar.cpp 
b/src/mathed/InsetMathSpecialChar.cpp
index 746cec5bda..12c9a4c111 100644
--- a/src/mathed/InsetMathSpecialChar.cpp
+++ b/src/mathed/InsetMathSpecialChar.cpp
@@ -139,7 +139,7 @@ void InsetMathSpecialChar::mathmlize(MathMLStream & ms) 
const
ms << "&";
break;
default:
-   ms.os().put(char_);
+   ms << char_;
break;
}
 }
diff --git a/src/mathed/MathStream.cpp b/src/mathed/MathStream.cpp
index 4a006e4809..dc4aa05df9 100644
--- a/src/mathed/MathStream.cpp
+++ b/src/mathed/MathStream.cpp
@@ -289,7 +289,7 @@ TeXMathStream & operator<<(TeXMathStream & ws, unsigned int 
i)
 
 
 MathMLStream::MathMLStream(odocstream & os, std::string const & xmlns)
-   : os_(os), tab_(0), line_(0), in_text_(false), xmlns_(xmlns)
+   : os_(os), xmlns_(xmlns)
 {
if (in_text_)
font_math_style_ = TEXT_STYLE;
@@ -338,23 +338,30 @@ MathMLStream & operator<<(MathMLStream & ms, MathData 
const & ar)
 }
 
 
-MathMLStream & operator<<(MathMLStream & ms, char const * s)
+MathMLStream & operator<<(MathMLStream & ms, docstring const & s)
 {
ms.os() << s;
return ms;
 }
 
 
+MathMLStream & operator<<(MathMLStream & ms, char const * s)
+{
+   ms << from_utf8(s);
+   return ms;
+}
+
+
 MathMLStream & operator<<(MathMLStream & ms, char c)
 {
-   ms.os() << c;
+   ms << docstring(1,c);
return ms;
 }
 
 
 MathMLStream & operator<<(MathMLStream & ms, char_type c)
 {
-   ms.os().put(c);
+   ms << docstring(1,c);
return ms;
 }
 
@@ -410,13 +417,6 @@ MathMLStream & operator<<(MathMLStream & ms, CTag const & 
t)
 }
 
 
-MathMLStream & operator<<(MathMLStream & ms, docstring const & s)
-{
-   ms.os() << s;
-   return ms;
-}
-
-
 //
 
 
diff --git a/src/mathed/MathStream.h b/src/mathed/MathStream.h
index 04c7cb507e..c8d684bc38 100644
--- a/src/mathed/MathStream.h
+++ b/src/mathed/MathStream.h
@@ -9,8 +9,8 @@
  * Full author contact details are available in file CREDITS.
  */
 
-#ifndef MATH_MATHMLSTREAM_H
-#define MATH_MATHMLSTREAM_H
+#ifndef MATH_MATHSTREAM_H
+#define MATH_MATHSTREAM_H
 
 #include "InsetMath.h"
 #include "FontInfo.h"
@@ -382,13 +382,9 @@ public:
void cr();
///
odocstream & os() { return os_; }
-   ///
-   int line() const { return line_; }
-   ///
+   /// Indentation when nesting tags
int & tab() { return tab_; }
///
-   friend MathMLStream & operator<<(MathMLStream &, char const *);
-   ///
void defer(docstring const &);
///
void defer(std::string const &);
@@ -412,11 +408,9 @@ private:
///
odocstream & os_;
///
-   int tab_;
-   ///
-   int line_;
+   int tab_ = 0;
///
-   bool in_text_;
+   bool in_text_ = false;
///
odocstringstream deferred_;
///
-- 
lyx-cvs mailing list
lyx-cvs@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-cvs

[LyX/master] Revert "Cmake build: Add Qt?Xml modules to build."

2024-07-22 Thread Jean-Marc Lasgouttes

commit cd4d54f76af59b3fba9e1d5565e463c28493f8cb
Author: Jean-Marc Lasgouttes 
Date:   Fri Jul 19 14:20:53 2024 +0200

Revert "Cmake build: Add Qt?Xml modules to build."

This reverts commit 01160486974a69e62e0b21490454e8dc2e0a4c8e.
---
 src/frontends/qt/CMakeLists.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/frontends/qt/CMakeLists.txt b/src/frontends/qt/CMakeLists.txt
index 65ed992c94..a007c2f492 100644
--- a/src/frontends/qt/CMakeLists.txt
+++ b/src/frontends/qt/CMakeLists.txt
@@ -47,14 +47,14 @@ endif()
 set_target_properties(frontend_qt PROPERTIES FOLDER "applications/LyX" 
QT_NO_UNICODE_DEFINES TRUE)
 
 if(Qt6Core_FOUND)
-   qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg Xml 
SvgWidgets)
+   qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg SvgWidgets)
 elseif(Qt5Core_FOUND AND APPLE)
-   qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg Xml 
MacExtras)
+   qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg MacExtras)
 else()
if (Qt5WinExtras_FOUND)
-   qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg Xml 
WinExtras)
+   qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg 
WinExtras)
else()
-  qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg Xml)
+   qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg)
endif()
 endif()
 target_link_libraries(frontend_qt
-- 
lyx-cvs mailing list
lyx-cvs@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-cvs

[LyX/master] Revert "Fix bug #13069."

2024-07-22 Thread Jean-Marc Lasgouttes

commit d7ba7bceb300c49ed1c3edb9b129810bb8a5160b
Author: Jean-Marc Lasgouttes 
Date:   Fri Jul 19 14:22:10 2024 +0200

Revert "Fix bug #13069."

This reverts commit fafe3ea5d7be1c06fb734e3bc621c551d617a6f7.
---
 config/qt.m4| 13 +++
 src/mathed/InsetMathBox.cpp | 95 ++---
 2 files changed, 53 insertions(+), 55 deletions(-)

diff --git a/config/qt.m4 b/config/qt.m4
index 64ffcd1213..6a455f9134 100644
--- a/config/qt.m4
+++ b/config/qt.m4
@@ -28,10 +28,10 @@ AC_DEFUN([QT_CHECK_COMPILE],
qt_guilibs="'-lQtCore -lQtGui' '-lQtCore4 -lQtGui4'"
if test $USE_QT6 = "yes" ; then
qt_corelibs="-lQt6Core"
-   qt_guilibs="-lQt6Core -lQt6Concurrent -lQt6Gui -lQt6Svg 
-lQt6Xml -lQt6Widgets"
+   qt_guilibs="-lQt6Core -lQt6Concurrent -lQt6Gui -lQt6Svg 
-lQt6Widgets"
else
qt_corelibs="-lQt5Core"
-   qt_guilibs="-lQt5Core -lQt5Concurrent -lQt5Gui -lQt5Svg 
-lQt5Xml -lQt5Widgets"
+   qt_guilibs="-lQt5Core -lQt5Concurrent -lQt5Gui -lQt5Svg 
-lQt5Widgets"
fi
for libname in $qt_corelibs '-framework QtCore'
do
@@ -43,8 +43,8 @@ AC_DEFUN([QT_CHECK_COMPILE],
done
qt_cv_libname=
for libname in $qt_guilibs \
-  '-framework QtCore -framework QtConcurrent 
-framework QtSvg -framework QtXml -framework QtWidgets -framework QtMacExtras 
-framework QtGui'\
-  '-framework QtCore -framework QtConcurrent 
-framework QtSvg -framework QtSvgWidgets -framework QtXml -framework QtWidgets 
-framework QtGui'\
+  '-framework QtCore -framework QtConcurrent 
-framework QtSvg -framework QtWidgets -framework QtMacExtras -framework QtGui'\
+  '-framework QtCore -framework QtConcurrent 
-framework QtSvg -framework QtSvgWidgets -framework QtWidgets -framework QtGui'\
   '-framework QtCore -framework QtGui'
do
QT_TRY_LINK($libname)
@@ -264,7 +264,7 @@ AC_DEFUN([QT_DO_PKG_CONFIG],
  export PKG_CONFIG_PATH
fi
qt_corelibs="Qt5Core"
-   qt_guilibs="Qt5Core Qt5Concurrent Qt5Gui Qt5Svg Qt5Widgets Qt5Xml"
+   qt_guilibs="Qt5Core Qt5Concurrent Qt5Gui Qt5Svg Qt5Widgets"
lyx_use_x11extras=false
PKG_CHECK_EXISTS(Qt5X11Extras, [lyx_use_x11extras=true], [])
if $lyx_use_x11extras; then
@@ -339,7 +339,7 @@ AC_DEFUN([QT_DO_MANUAL_CONFIG],
QT_CORE_LDFLAGS=
if test -n "$qt_cv_includes"; then
QT_INCLUDES="-I$qt_cv_includes"
-   for i in Qt QtCore QtGui QtWidgets QtSvg QtConcurrent 
QtSvgWidgets QtXml QtMacExtras; do
+   for i in Qt QtCore QtGui QtWidgets QtSvg QtConcurrent 
QtSvgWidgets QtMacExtras; do
QT_INCLUDES="$QT_INCLUDES -I$qt_cv_includes/$i"
if test "$lyx_use_packaging" = "macosx" ; then
QT_INCLUDES="$QT_INCLUDES 
-I$qt_cv_libraries/${i}.framework/Headers"
@@ -435,7 +435,6 @@ qtHaveModule(concurrent){QT += concurrent} else 
{MISSING += concurrent}
 qtHaveModule(gui)  {QT += gui} else {MISSING += gui}
 qtHaveModule(gui-private)  {QT += gui-private} else {MISSING += 
gui-private}
 qtHaveModule(svg)  {QT += svg} else {MISSING += svg}
-qtHaveModule(xml)  {QT += xml} else {MISSING += xml}
 qtHaveModule(widgets)  {QT += widgets} else {MISSING += widgets}
 EOF2
if test "$qt_major" = 6; then
diff --git a/src/mathed/InsetMathBox.cpp b/src/mathed/InsetMathBox.cpp
index 09a0a0f351..6feddf9cdd 100644
--- a/src/mathed/InsetMathBox.cpp
+++ b/src/mathed/InsetMathBox.cpp
@@ -28,10 +28,6 @@
 #include 
 #include 
 
-#include 
-#include 
-#include "support/qstring_helpers.h"
-
 using namespace lyx::support;
 
 namespace lyx {
@@ -66,10 +62,6 @@ namespace {
 void splitAndWrapInMText(MathMLStream & ms, MathData const & cell,
 const std::string & attributes)
 {
-// The goal of this function is to take an XML fragment and wrap
-// anything that is outside of any tag in  tags,
-// then wrap the whole thing in an  tag with attributes
-
// First, generate the inset into a string of its own.
docstring inset_contents;
{
@@ -82,46 +74,53 @@ void splitAndWrapInMText(MathMLStream & ms, MathData const 
& cell,
inset_contents = ostmp.str();
}

sieve mail date change

2024-07-22 Thread Marc via dovecot

I am a bit rookie with sieve. Some time ago I created a sieve pipe that would 
sometimes alter alter the subject and move a message to a different mailbox. 
Currently this results in that a date changes of this message while I don't see 
anything in the source altering a date. 

What could be causing this and how to work around this?
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: FW: Lyx 2.4 - strange rendering problem in Windows

2024-07-22 Thread Jean-Marc Lasgouttes


Le 05/06/2024 à 17:09, Dr Paul Verschueren a écrit :

Thanks to all for making 2.4 a reality😊.

I’ve just installed on Win11 and have a strange issue: when a document 
is scrolled or moved up or down, a ghost image is left behind (see 
screenshot below).


Dear Paul,

Good news: this will be fixed in LyX 2.4.2. In the meantime, you can 
disable 'use system colors' in Preferences | Look&Feel | Colors.


Hope this helps,
JMarc
--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

[LyX/master] Remove alpha component of system colors

2024-07-22 Thread Jean-Marc Lasgouttes

commit 095bb18331f8eb4653691a64520d89d4a2d60fc4
Author: Jean-Marc Lasgouttes 
Date:   Mon Jul 22 20:36:20 2024 +0200

Remove alpha component of system colors

When using system colors it may happen (on windows 11 in particular)
that the background color is actually translucid. This is not
something we are prepared to handle and it creates ghosts on screen.

The fix is easy: the alpha channel of the colors is set to 255.

Fixes bug #13084.
---
 src/frontends/qt/ColorCache.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/frontends/qt/ColorCache.cpp b/src/frontends/qt/ColorCache.cpp
index 1c3d68e548..2566b75025 100644
--- a/src/frontends/qt/ColorCache.cpp
+++ b/src/frontends/qt/ColorCache.cpp
@@ -86,7 +86,9 @@ QColor ColorCache::get(Color const & color, bool syscolors) 
const
QPalette::ColorRole const cr = role(color.baseColor);
if (syscolors && cr != QPalette::NoRole) {
static QColor const white = Qt::white;
-   QColor const c = pal_.brush(QPalette::Active, 
cr).color();
+   QColor c = pal_.brush(QPalette::Active, cr).color();
+   // Change to fully opaque color
+   c.setAlpha(255);
if (cr == QPalette::Base && c == white)
return lcolors_[color.baseColor];
else
-- 
lyx-cvs mailing list
lyx-cvs@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-cvs

Re: Numbers in library names

2024-07-22 Thread Marc Nieper-Wißkirchen

Am Mo., 22. Juli 2024 um 19:43 Uhr schrieb Lassi Kortela :

> > To correctly attach marks (in the R6RS syntax model) to the imported
> > identifiers, the expander needs marks associated with the library name
> > (and takes the marks of the last name part, which, therefore, must be an
> > identifier).
> Where does the decision to take the last library name part come from?
>
> Only Chez Scheme? Any other implementations? Does R6RS address this?
>

As I wrote, this is a syntactic extension of Chez Scheme - but a very
useful one - and outside of the R6RS.  The Unsyntax expander I wrote also
implements it.


> Why not take the first library name part instead of the last? In
> practice, a numeric last part is useful and is already widely used. It's
> far less likely for a numeric first part to be useful.
>

The last name part is the most specific one.  In any case, the decision was
made before R7RS existed, and, as I mentioned, the R7RS authors were likely
unaware of the incompatibility of their proposal to allow numeric name
parts with existing implementations and language extensions.

I don't buy that numeric library parts are particularly useful; they are
just one option. The SRFI 97 convention works as well as the SRFI-0
convention of "srfi-N" names, which is basically also used by Guile.

[Bug 2073515] Re: functionality loss in mod_proxy rewritten path

2024-07-22 Thread Marc Deslauriers

Thanks, that is very helpful, so we're getting an extra slash here:

rewrite '/asd.example.com/' -> 'http:///asd:8000/'

instead of:

rewrite '/asd.example.com/' -> 'http://asd:8000/'

and I can confirm this issue exists with upstream's 2.4.62 release too,
so I will keep an eye out for new fixes they have been adding post-
release.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073515

Title:
  functionality loss in mod_proxy rewritten path

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/2073515/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [PATCH] drivers/watchdog: add eiois200 wdt driver

2024-07-22 Thread Marc Ferland

On Sun, Jul 21, 2024 at 9:19 AM Jan Kiszka  wrote:
>
> On 17.07.24 17:15, marc.ferl...@gmail.com wrote:
> > From: Marc Ferland 
> >
> > This driver adds support for the WDT included in Advantechs's EC
> > chip (EIOIS200). Unfortunatly, no documentation is available at this
> > time and so the driver was inspired from the code available at:
> >
> > https://github.com/ADVANTECH-Corp/eio-is200-linux-kernel-driver
>
> Thanks for the patch. I saw you trying to contribute to that downstream
> driver as well. Is anyone working on properly upstreaming all those
> bits? You already found issues, and I bet the respective subsystem
> maintainer will found some more.
>
I don't think so. Advantech tried to do it but ultimately decided it was too
much effort I guess...
See: https://lore.kernel.org/lkml/?q=eiois200

And yes, there are many issues with the original driver!

> >
> > This driver was tested on the SOM-6872.
> >
> > Signed-off-by: Marc Ferland 
> > ---
> >  Makefile.am |   1 +
> >  drivers/watchdog/eiois200_wdt.c | 442 
> >  2 files changed, 443 insertions(+)
> >  create mode 100644 drivers/watchdog/eiois200_wdt.c
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 2ea47ae..34a7ee7 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -175,6 +175,7 @@ efi_sources_watchdogs = \
> >   drivers/watchdog/ipmi_wdt.c \
> >   drivers/watchdog/itco.c \
> >   drivers/watchdog/hpwdt.c \
> > + drivers/watchdog/eiois200_wdt.c \
> >   drivers/utils/simatic.c \
> >   drivers/utils/smbios.c
> >  else
> > diff --git a/drivers/watchdog/eiois200_wdt.c 
> > b/drivers/watchdog/eiois200_wdt.c
> > new file mode 100644
> > index 000..1459c2b
> > --- /dev/null
> > +++ b/drivers/watchdog/eiois200_wdt.c
> > @@ -0,0 +1,442 @@
> > +/*
> > + * EFI Boot Guard
> > + *
> > + * Copyright (c) Sonatest AP Inc, 2024
> > + *
> > + * Authors:
> > + *  Marc Ferland 
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2.  See
> > + * the COPYING file in the top-level directory.
> > + *
> > + * SPDX-License-Identifier:  GPL-2.0
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "utils.h"
> > +
> > +/* #define EIO200IS_WDT_DEBUG */
> > +
> > +#ifdef EIO200IS_WDT_DEBUG
> > +#define DBG(fmt, ...) Print(fmt, ##__VA_ARGS__)
> > +#else
> > +#define DBG(fmt, ...) {}
> > +#endif
> > +
> > +#define EIOIS200_MODE_ENTER  0x87
> > +#define EIOIS200_MODE_EXIT   0xaa
> > +#define EIOIS200_CHIPID1 0x20
> > +#define EIOIS200_CHIPID2 0x21
> > +#define EIOIS200_200_CHIPID  0x9610
> > +#define EIOIS200_211_CHIPID  0x9620
> > +#define EIOIS200_SIOCTRL 0x23
> > +#define EIOIS200_SIOCTRL_SIOEN   (1 << 0)
> > +#define EIOIS200_SIOCTRL_SWRST   (1 << 1)
> > +#define EIOIS200_IRQCTRL 0x70
> > +
> > +#define EIOIS200_PMC_STATUS_IBF  (1 << 1)
> > +#define EIOIS200_PMC_STATUS_OBF  (1 << 0)
> > +#define EIOIS200_LDAR0x30
> > +#define EIOIS200_LDAR_LDACT  (1 << 0)
> > +#define EIOIS200_IOBA0H  0x60
> > +#define EIOIS200_IOBA0L  0x61
> > +#define EIOIS200_IOBA1H  0x62
> > +#define EIOIS200_IOBA1L  0x63
> > +#define EIOIS200_FLAG_PMC_READ   (1 << 0)
> > +
> > +#define PMC_WDT_CMD_WRITE0x2a
> > +#define PMC_WDT_CMD_READ 0x2b
> > +#define PMC_WDT_CTRL_START   0x01
> > +#define PMC_WDT_MIN_TIMEOUT_MS   1000
> > +#define PMC_WDT_MAX_TIMEOUT_MS   32767000
> > +
> > +#define WDT_STA_AVAILABLE(1 << 0)
> > +#define WDT_STA_RESET(1 << 7)
> > +
> > +#define WDT_REG_STATUS   0x00
> > +#define WDT_REG_CONTROL  0x02
> > +#define WDT_REG_RESET_EVT_TIME   0x14
> > +
> > +/* Logical device selection */
> > +#define EIOIS200_LDN 0x07 /* index */
> > +#define EIOIS200_LDN_PMC00x0c /* value */
> > +#define EIOIS200_LDN_PMC10x0d /* value */
> > +
> > +enum eiois200_port_id {
> > + EIOIS200_P

[Bug 2073515] Re: functionality loss in mod_proxy rewritten path

2024-07-22 Thread Marc Deslauriers

I'm having difficulty reproducing your exact issue. Could you please run
apache with "rewrite:trace3" and show working and non-working requests
from error.log? Thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2073515

Title:
  functionality loss in mod_proxy rewritten path

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/2073515/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [packman] Inquiry on Mirroring Packman Repositories and Seeking Official Synchronization

2024-07-22 Thread Marc Schiffbauer

* Dominik Heidler schrieb am 22.07.24 um 14:22 Uhr:
> Hi,
> 
> if you add a new mirror, please let me know so that I can add it to the list 
> in
> https://github.com/openSUSE/opi/blob/master/opi/__init__.py#L120
> 
> Or simply create a PR.
> 
> Then the OPI cli tool will include it in the list when adding the packman 
> repo.

Could you maybe add some function that will automatically retrieve a 
list of official mirrors? That would greatly simplfy it.

If you need some specific format or something like that, then let me 
know!

Cheers
-Marc


___
Packman mailing list
Packman@links2linux.de
https://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] Inquiry on Mirroring Packman Repositories and Seeking Official Synchronization

2024-07-22 Thread Marc Schiffbauer

* mirrors(SNG 腾讯云软件源) schrieb am 12.07.24 um 03:02 Uhr:
> Dear Packman Team,
>
> Greetings!

Hi motorao,

as one of the founders of packman I am answering you here and trying to 
clarify thing for you.

First of all: Thanks for asking!

> 
> My name is motorao and I am reaching out on behalf of TencentCloud.
> Our team has been providing a mirror service for the Packman software
> repositories（https://mirrors.tencent.com/packman/）, aiming to
> enhance accessibility and speed for our local user community. However,
> we have not identified any explicit statements on your website that
> address or permit the synchronization and redistribution of your
> content by third parties.

This is nice!

> Given our commitment to compliance, we are reaching out for
> clarification and to seek official guidance. Specifically, we are
> interested in: 
> 1. Whether we have the authorization to legally
>synchronize and proxy the Packman software repositories.
> 2. Understanding any specific compliance requirements or
>authorization processes we must follow.  
> 3. Receiving any official terms of use or authorization documents that
>would validate our synchronization efforts.

We are happy to have mirrors. The more, the better. At this point we 
have some "official" mirrors. These are mentioned in the MIRRORS file 
you can finde in the repo or at http://packman.links2linux.org/mirrors

> Additionally, we are curious if there is a recommended method or best
> practice for repository synchronization that is endorsed by
> Packman（is this rsync url officially served
> ：rsync://mirror.karneval.cz/packman/）. Knowing the official stance
> and recommended practices would greatly assist us in ensuring that our
> mirror service aligns with Packman's standards and policies.
> 
> We are dedicated to respecting intellectual property and copyright
> laws and are committed to operating within the boundaries of any
> permissions granted. We hope to establish a cooperative relationship
> with the Packman team and contribute positively to the community.
> 
> Thank you for considering our request. We eagerly await your guidance
> on this matter.

My suggestion is you become an official mirror! You will get 
rsync-access to the primary repo so you can be sure to be really 
up-to-date.

We provide a little shell-script to primary mirrors that will include 
all required commands to setup and run the mirror smoothly.

Because initial sync can be slow it is very good, that you have all the 
mirror-data already, so you do not need to start from scratch.

Please drop me an email to my address and we can then setup everything.

Cheers
-Marc


___
Packman mailing list
Packman@links2linux.de
https://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [packman] NA Mirrors

2024-07-22 Thread Marc Schiffbauer

* Collin MacDonald schrieb am 19.07.24 um 22:54 Uhr:
> Hi! 👋

Hi Collin,

> I was watching this YouTube video,
> <https://www.youtube.com/watch?v=ir9ujC1BLfY> and the creator mentioned
> that there aren't any Packman mirrors in the NA region. I'm hoping to find
> out more about what getting that set up might entail as it could greatly
> improve the experience for NA users. Any insight would be appreciated.

Sounds good!

You would need a Server with static IP(v4/v6) and enough space to mirror 
the repo. If thats the case then please drop me an email and we make you 
driving a primary mirror.

Thanks
-Marc


___
Packman mailing list
Packman@links2linux.de
https://lists.links2linux.de/cgi-bin/mailman/listinfo/packman

Re: [PATCH qemu] ui/gtk: Reuse input event slots for GdkEventTouch

2024-07-22 Thread Marc-André Lureau

Hi

On Mon, Jul 22, 2024 at 3:58 PM Sergio Lopez Pascual  wrote:

> Marc-André Lureau  writes:
>
> > Hi
> >
> > Adding Sergio in CC, who wrote that code. I don't have means to test it,
> > which also limits my understanding and ability to check this.
> >
> > On Sat, Jul 20, 2024 at 11:58 PM ~katharine_chui <
> katharine_c...@git.sr.ht>
> > wrote:
> >
> >> From: Katharine Chui 
> >>
> >> There seems to be no guarantee as to how GdkEventTouch.sequence
> >> would progress https://docs.gtk.org/gdk3/struct.EventTouch.html
> >>
> >>
> > True, we also abuse the internal implementation which stores low integers
> > in the sequence pointer.
> >
> > In the case of steam gamescope session, touch input would
> >> increment the number every touch, resulting in all touch inputs
> >> after the 10th touch to get dropped
> >>
> >> ...
> >> qemu: warning: Unexpected touch slot number:  10 >= 10
> >> qemu: warning: Unexpected touch slot number:  11 >= 10
> >> qemu: warning: Unexpected touch slot number:  12 >= 10
> >> qemu: warning: Unexpected touch slot number:  13 >= 10
> >> qemu: warning: Unexpected touch slot number:  14 >= 10
> >> ...
> >>
> >> Reuse the slots on gtk to avoid that
> >>
> >
> > But doing modulo like this, there is a chance of conflict with already
> used
> > slots.
> >
> > Maybe it's time for a better gtk implementation which would handle a
> proper
> > sequence pointer to slot mapping.
>
> The problem with slots vs. sequences is that, from what I can see,
> there's not way to obtain the slot number from EventTouch, which makes
> me thing we're a little to high in the abstraction layer to emulate
> multi-touch properly. And with GTK4 it seems to be even worse, because
> it tries harder to process gestures on its own (we need them to be
> processed by the guest instead).
>
> Under some compositors, we were lucky enough that indeed slots ==
> sequences, so we could actually pass those events as that and have the
> guest process and recognize simple gestures (i.e. pinching) properly.
>
> The "right" solution would be finding a way to operate at a lower level
> than what EventTouch provides us today, but I don't know how feasible is
> that from within the limits of the ui/gtk3.c.
>
> In case that's not possible, the modulo workaround is probably as good
> as we can get.
>

Can't we map the sequence pointer to a (reusable) counter? So up to
max-slots sequences could be mapped uniquely and we would reject events
that do not fit within max-slots.


-- 
Marc-André Lureau

[MariaDB discuss] Re: possible bug in dropping max connections

2024-07-22 Thread Marc via discuss

Hi Sergei,

> 
> Not quite. max_user_connections limit is enforced after successful
> authentication - that's when the server knows the user name.
> 
> max_connections is enforced as soon as the client connects.
> 
> So yes, even when usera has reached max_user_connections limit, it can
> keep trying to connect and exhaust max_connections too, especially if
> it'll delay sending authentication packets.

So what about waiting a bit with dropping the connection of max_connections, so 
you can do

- get the send user name
- check if the username is in max_user_connections limit
- if it is limited drop the connection, but don't add it to the max_connections 
counter.
- if it is not limited add the connection, and add it to max_connections 
counter.

disadvantage 
- is when you drop the connection for max_connections. You have to maybe 
postpone this a bit.
- could this postponing be abused in a dos attack?

advantage
- is you allow other not blocked users from the same ip.
- admins don't need to set max_connections high to prevent it from blocking 
other valid users
- keep this max_connections functionality as it is meant for.

I think this is a good enhancement. Depending on postponing this dropping. In 
sendmail you have a delayed_checks option. You could also add this to the 
configuration activating this behaviour. So people can choose to have this 
functionality or not. It all depends on the influence of postponing dropping a 
connection until you know what the user name is.
Afaik is the current combination of max_user_connections and max_connections 
useles when on the same ip. 



___
discuss mailing list -- discuss@lists.mariadb.org
To unsubscribe send an email to discuss-le...@lists.mariadb.org

RE: DATE_IN_FUTURE_24_48 more often?

2024-07-22 Thread Marc

> 
> >
> > > I think I am starting to see this more often. Today I was checking
> > > again every server to see if the ntp time is syncing properly. But
> > > don't notice anything weird, can't really believe this sending had a
> > > bad clock. Can anyone suggest what/where to look for?
> > >
> > >
> > > DATE_IN_FUTURE_24_48 Date: is 24 to 48 hours after
> >
> > When you  looked at the Date: header, what did it say?   The part of
> > your question where you gave an example didn't make it through the
> > mailinglist!
> 
> I was wondering if I am the only one seeing this. Could also be related
> to my transitioning to el9. I can remember having to change some scripts
> for time/timezone. Logged times seem ok:
> 
> mta logging was on this date: Jul  4 08:51:37
> message header Date: Thu, 4 Jul 2024 08:51:35 +0200
> message header Received:   Thu, 4 Jul 2024 08:51:37 +0200

This does not look like something out of the ordinary not? Even if it is a 
timezone/summertime issue it is still not 'is 24 to 48 hours after'

Re: [PATCH] chardev/char-win-stdio.c: restore old console mode

2024-07-22 Thread Marc-André Lureau

On Mon, Jul 22, 2024 at 1:19 PM songziming  wrote:

> Hi
>
> I've updated the patch.
>
> Now it only reset mode if handle is valid.
>
>
you lost the commit message, and the subject does not' have a version tag
(see
https://www.qemu.org/docs/master/devel/submitting-a-patch.html#when-resending-patches-add-a-version-tag
)

thanks


> Signed-off-by: Ziming Song 
>

> ---
>  chardev/char-win-stdio.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/chardev/char-win-stdio.c b/chardev/char-win-stdio.c
> index 1a18999..13325ca 100644
> --- a/chardev/char-win-stdio.c
> +++ b/chardev/char-win-stdio.c
> @@ -33,6 +33,7 @@
>  struct WinStdioChardev {
>  Chardev parent;
>  HANDLE  hStdIn;
> +DWORD   dwOldMode;
>  HANDLE  hInputReadyEvent;
>  HANDLE  hInputDoneEvent;
>  HANDLE  hInputThread;
> @@ -159,6 +160,7 @@ static void qemu_chr_open_stdio(Chardev *chr,
>  }
>
>  is_console = GetConsoleMode(stdio->hStdIn, &dwMode) != 0;
> +stdio->dwOldMode = dwMode;
>
>  if (is_console) {
>  if (qemu_add_wait_object(stdio->hStdIn,
> @@ -221,6 +223,9 @@ static void char_win_stdio_finalize(Object *obj)
>  {
>  WinStdioChardev *stdio = WIN_STDIO_CHARDEV(obj);
>
> +if (stdio->hStdIn != INVALID_HANDLE_VALUE) {
> +SetConsoleMode(stdio->hStdIn, stdio->dwOldMode);
> +}
>      if (stdio->hInputReadyEvent != INVALID_HANDLE_VALUE) {
>  CloseHandle(stdio->hInputReadyEvent);
>  }
> --
> 2.34.1.windows.1
>
>
>

-- 
Marc-André Lureau

Re: Are library names data or syntax?

2024-07-22 Thread Marc Nieper-Wißkirchen

Am Mo., 22. Juli 2024 um 10:13 Uhr schrieb Taylan Kammer <
taylan.kam...@gmail.com>:

> Thank you for the comments. I agree especially with the part about RnRS
> needing to define a broad-ranging standard that allows writing useful
> libraries in a portable way. The lack of e.g. networking primitives is
> extremely limiting and this always greatly bothered me about RnRS.
>
> I have questions about your point #4 though.
>
> On 21.07.2024 11:54, Marc Nieper-Wißkirchen wrote:
>
> > Allowing numbers in library names makes certain syntactic extensions (as
> some found in Chez Scheme) impossible.
>
> Do you have a pointer to some resource that explains this in more detail?
> It's the first time I'm hearing about it and would like to learn more.
>
> > In the syntax-case model of R6RS (which is also the basis of Guile's
> expander), only identifiers like ":1" carry lexical information (a set of
> marks and substitutions in the R6RS model), numbers and other Scheme datums
> do not.
>
> I've always thought of library names as data, not identifiers...
>
> In R7RS, both 'define-library' and 'import' kind of exist "outside" the
> rest of the language, in a sense, and treat library names as literals.
>
> - 'define-library' must be the outermost form read from a
> file/stream/whatever, and neither the library name being defined nor any of
> the library names in 'import' sub-forms are subject to variable lookup or
> any such mechanisms that otherwise affect Scheme program evaluation; the
> library names are all treated literally, like data.
>
> - 'import' (when not used a 'define-library' subform) must appear one or
> more times at the start of a sequence of forms read from a
> file/stream/whatever that describes a program, and the library name
> operands are again not subject to variable lookup or such, but rather
> treated literally as if data.
>
> - The only other entity in R7RS that deals with library names, if I
> remember correctly, is the 'environment' procedure, which expects library
> names in the form of data (lists).
>
> In what kind of situation might a library name be made up of identifiers
> (syntax objects) that might need to carry lexical information?
>

I was talking about certain syntactic extensions. In Chez Scheme, which is
an extension of R6RS (and strictly compatible with it modulo bugs),
"import" is also a keyword, and libraries can be imported into a local
environment. In this case, the library name is part of the syntax. To
correctly attach marks (in the R6RS syntax model) to the imported
identifiers, the expander needs marks associated with the library name (and
takes the marks of the last name part, which, therefore, must be an
identifier).

Local imports make perfect sense; they are just not standardised in current
RnRS versions, i.e., in R6RS and R7RS.  Likewise, future standards may
allow library forms within Scheme program text.  The R7RS choice of
allowing numbers is, thus, suboptimal because it may rule out certain
future extensions.

I guess there is another reason why R6RS disallows numbers as library
names: this can lead to confusion with library versions, which are also
numeric (and which R7RS does not have).  People coming from other
programming languages or environments are used to numbers as version
indicates (e.g., we have libguile-2.2.so and libguile-3.0.so), while "(srfi
1)" does not mean the first version of some SRFI library. (We really need a
better naming scheme for SRFI libraries that does not depend on assigned
numbers, but it is not clear to me how to implement one.)

Cheers,

Marc

Re: [PATCH v3] chardev: add path option for pty backend

2024-07-22 Thread Marc-André Lureau

Hi Octavian,

You should send a new version with the changes requested by Markus. (we
might miss 9.1 though)

On Thu, Jul 18, 2024 at 1:48 PM Markus Armbruster  wrote:

> Peter Maydell  writes:
>
> > On Thu, 18 Jul 2024 at 07:15, Markus Armbruster 
> wrote:
> >>
> >> Looks like this one fell through the cracks.
> >>
> >> Octavian Purdila  writes:
> >>
> >> > Add path option to the pty char backend which will create a symbolic
> >> > link to the given path that points to the allocated PTY.
> >> >
> >> > This avoids having to make QMP or HMP monitor queries to find out what
> >> > the new PTY device path is.
> >>
> >> QMP commands chardev-add and chardev-change return the information you
> >> want:
> >>
> >> # @pty: name of the slave pseudoterminal device, present if and only
> >> # if a chardev of type 'pty' was created
> >>
> >> So does HMP command chardev-add.  HMP chardev apparently doesn't, but
> >> that could be fixed.
> >>
> >> So, the use case is basically the command line, right?
> >
> >> The feature feels rather doubtful to me, to be honest.
> >
> > The command line is an important use-case, though. Not every
> > user of QEMU is libvirt with a QMP/HMP connection readily
> > to hand that they would prefer to use for all configuration...
>
> In general yes.  But what are the use cases for this one?
>
> To me, specifying path=/mumble/symlink plus the bother of cleaning up
> stale ones doesn't feel like much of an improvement over reading the pty
> name from "info chardev".  I guess I'm missing something.  Tell me!
>
> If we decide we want this, then the QMP interface needs to be fixed:
> Call the argument @path for consistency, and document it properly.
> Actually straightforward, just create a new struct instead of pressing
> ChardevHostdev into service.
>
> Some advice on robust use of @path could be useful, in particular on
> guarding against QEMU leaving stale links behind.
>
> Additional decision: whether to extend the old-style syntax.
>
>
>

-- 
Marc-André Lureau

Re: [PATCH qemu] ui/gtk: Reuse input event slots for GdkEventTouch

2024-07-22 Thread Marc-André Lureau

Hi

Adding Sergio in CC, who wrote that code. I don't have means to test it,
which also limits my understanding and ability to check this.

On Sat, Jul 20, 2024 at 11:58 PM ~katharine_chui 
wrote:

> From: Katharine Chui 
>
> There seems to be no guarantee as to how GdkEventTouch.sequence
> would progress https://docs.gtk.org/gdk3/struct.EventTouch.html
>
>
True, we also abuse the internal implementation which stores low integers
in the sequence pointer.

In the case of steam gamescope session, touch input would
> increment the number every touch, resulting in all touch inputs
> after the 10th touch to get dropped
>
> ...
> qemu: warning: Unexpected touch slot number:  10 >= 10
> qemu: warning: Unexpected touch slot number:  11 >= 10
> qemu: warning: Unexpected touch slot number:  12 >= 10
> qemu: warning: Unexpected touch slot number:  13 >= 10
> qemu: warning: Unexpected touch slot number:  14 >= 10
> ...
>
> Reuse the slots on gtk to avoid that
>

But doing modulo like this, there is a chance of conflict with already used
slots.

Maybe it's time for a better gtk implementation which would handle a proper
sequence pointer to slot mapping.


>
> Signed-off-by: Katharine Chui 
> ---
>  ui/gtk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ui/gtk.c b/ui/gtk.c
> index bc29f7a1b4..b123c9616d 100644
> --- a/ui/gtk.c
> +++ b/ui/gtk.c
> @@ -1090,7 +1090,7 @@ static gboolean gd_touch_event(GtkWidget *widget,
> GdkEventTouch *touch,
> void *opaque)
>  {
>  VirtualConsole *vc = opaque;
> -uint64_t num_slot = GPOINTER_TO_UINT(touch->sequence);
> +uint64_t num_slot = GPOINTER_TO_UINT(touch->sequence) %
> INPUT_EVENT_SLOTS_MAX;
>  int type = -1;
>
>  switch (touch->type) {
> --
> 2.43.4
>
>

-- 
Marc-André Lureau

Bug#1076667: aide: AIDE stops working with an error if there is a subdirectory in /etc/apt/sources.list.d

2024-07-22 Thread Marc Haber

Control: tag -1 confirmed wontfix

On Sun, Jul 21, 2024 at 03:03:51PM +0200, Barchan barchan wrote:
> If there is a subdirectory in this directory (in my case it was a
> backup directory created during the update to the next stable
> version), the aide script crashes with an error:

I regret that bug and easily find your report plausible.

This is however not going to be fixed in a stable release update. The
next stable release will most probably contain aide 0.19, which does the
reading of the .d directory itself. The faulty code will therefore not
be present in the next release.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: [PATCH] chardev/char-win-stdio.c: restore old console mode

2024-07-22 Thread Marc-André Lureau

Hi

On Mon, Jul 22, 2024 at 12:01 AM songziming  wrote:

> If I use `-serial stdio` on Windows, after QEMU exits, the terminal
> could not handle arrow keys and tab any more. Because stdio backend
> on Windows sets console mode to virtual terminal input when starts,
> but does not restore the old mode when finalize.
>
> This small patch saves the old console mode and set it back.
>

Thanks, we had a similar patch from Irina Ryapolova, but it didn't save the
old mode and she didn't update it.


> Signed-off-by: Ziming Song 
>

> ---
>  chardev/char-win-stdio.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/chardev/char-win-stdio.c b/chardev/char-win-stdio.c
> index 1a18999..5b24893 100644
> --- a/chardev/char-win-stdio.c
> +++ b/chardev/char-win-stdio.c
> @@ -33,6 +33,7 @@
>  struct WinStdioChardev {
>  Chardev parent;
>  HANDLE  hStdIn;
> +DWORD   dwOldMode;
>  HANDLE  hInputReadyEvent;
>  HANDLE  hInputDoneEvent;
>  HANDLE  hInputThread;
> @@ -159,6 +160,7 @@ static void qemu_chr_open_stdio(Chardev *chr,
>  }
>
>  is_console = GetConsoleMode(stdio->hStdIn, &dwMode) != 0;
> +stdio->dwOldMode = dwMode;
>
>  if (is_console) {
>  if (qemu_add_wait_object(stdio->hStdIn,
> @@ -220,6 +222,7 @@ err1:
>  static void char_win_stdio_finalize(Object *obj)
>  {
>  WinStdioChardev *stdio = WIN_STDIO_CHARDEV(obj);
> +SetConsoleMode(stdio->hStdIn, stdio->dwOldMode);
>
>
It should not reset if the open callback was not called successfully.

You can check if it's the case by adding a if (stdio->hStdIn !=
INVALID_HANDLE_VALUE) condition.

 if (stdio->hInputReadyEvent != INVALID_HANDLE_VALUE) {
>  CloseHandle(stdio->hInputReadyEvent);
> --
> 2.45.1.windows.1
>
>
>

-- 
Marc-André Lureau

Re: [PATCH 12/13] dump: make range overlap check more readable

2024-07-22 Thread Marc-André Lureau

On Mon, Jul 22, 2024 at 8:10 AM Yao Xingtao  wrote:

> use ranges_overlap() instead of open-coding the overlap check to improve
> the readability of the code.
>
> Signed-off-by: Yao Xingtao 
>

Reviewed-by: Marc-André Lureau 


> ---
>  dump/dump.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/dump/dump.c b/dump/dump.c
> index 84064d890d2c..45e84428aea5 100644
> --- a/dump/dump.c
> +++ b/dump/dump.c
> @@ -30,6 +30,7 @@
>  #include "migration/blocker.h"
>  #include "hw/core/cpu.h"
>  #include "win_dump.h"
> +#include "qemu/range.h"
>
>  #include 
>  #ifdef CONFIG_LZO
> @@ -574,8 +575,10 @@ static void get_offset_range(hwaddr phys_addr,
>
>  QTAILQ_FOREACH(block, &s->guest_phys_blocks.head, next) {
>  if (dump_has_filter(s)) {
> -if (block->target_start >= s->filter_area_begin +
> s->filter_area_length ||
> -block->target_end <= s->filter_area_begin) {
> +if (!ranges_overlap(block->target_start,
> +block->target_end - block->target_start,
> +s->filter_area_begin,
> +s->filter_area_length)) {
>  /* This block is out of the range */
>  continue;
>  }
> @@ -734,8 +737,9 @@ int64_t dump_filtered_memblock_start(GuestPhysBlock
> *block,
>  {
>  if (filter_area_length) {
>  /* return -1 if the block is not within filter area */
> -if (block->target_start >= filter_area_start + filter_area_length
> ||
> -block->target_end <= filter_area_start) {
> +if (!ranges_overlap(block->target_start,
> +block->target_end - block->target_start,
> +filter_area_start, filter_area_length)) {
>  return -1;
>  }
>
> --
> 2.41.0
>
>

Re: [PATCH] use yellow background for math comments

2024-07-21 Thread Jean-Marc Lasgouttes


Le 21/07/2024 à 09:49, José Matos a écrit :

Actually it was more (for me a least) import that you applied one of
the changes. Personally I prefer your first option but even the second
option would be better than not to do nothing.

I suppose that we can improve our communication skills and avoid you
having to use the Cerebro, professor X. :-D


To be frank, I am not really interested in this math comment thing, so I 
prefer this outcome that doing two weeks of back-and-forth.


But be warned now that ignoring me is not enough to escape my changes ;)

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[PATCH] WIP: rewrite statistics code

2024-07-21 Thread Jean-Marc Lasgouttes




The statistics code is known to be very slow, because it relies on
DocIterator to go through the buffer.

This commit introduces a new Statitistics class that encapsulates the
main code, along a virtual method Inset::updateStatistics() that
allows to fine-tune how counting is done inset by inset.

In order to check that it works, the old code is not removed yet, and
Tools>Statistics displays the result of the two methods on the
console. I used in particular the user guide to check that the results
are the same.

The display in the status bar has switched to the new code.

The commit does also some profiling with pmprof and outputs some
timings when exiting LyX. I see consistently that the new code is 3x
faster.

Of course, this duplicated code will be removed when finalizing the
commit.

Please test.

JMarcFrom 55846d62d16efa52b406ec441856a1da8a9b6b20 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Sun, 21 Jul 2024 22:09:28 +0200
Subject: [PATCH] WIP: rewrite statistics code

The statistics code is known to be very slow, because it relies on
DocIterator to go through the buffer.

This commit introduces a new Statitistics class that encapsulates the
main code, along a virtual method Inset::updateStatistics() that
allows to fine-tune how counting is done inset by inset.

In order to check that it works, the old code is not removed yet, and
Tools>Statistics displays the result of the two methods on the
console. I used in particular the user guide to check that the results
are the same.

The display in the status bar has switched to the new code.

The commit does also some profiling with pmprof and outputs some
timings when exiting LyX. I see consistently that the new code is 3x
faster.

Of course, this duplicated code will be removed when finalizing the
commit.
---
 src/Buffer.cpp|  12 +++-
 src/Buffer.h  |   2 +
 src/BufferView.cpp|  21 ++
 src/Makefile.am   |   2 +
 src/Statistics.cpp| 120 ++
 src/Statistics.h  |  64 ++
 src/frontends/qt/GuiView.cpp  |  23 ++-
 src/insets/Inset.cpp  |  14 +++-
 src/insets/Inset.h|   3 +
 src/insets/InsetCitation.cpp  |   7 ++
 src/insets/InsetCitation.h|   2 +
 src/insets/InsetHyperlink.cpp |   9 ++-
 src/insets/InsetHyperlink.h   |   2 +
 src/insets/InsetQuotes.cpp|  24 +++
 src/insets/InsetQuotes.h  |   2 +
 src/insets/InsetTabular.cpp   |   8 +++
 src/insets/InsetTabular.h |   3 +
 src/insets/InsetText.cpp  |   7 ++
 src/insets/InsetText.h|   3 +
 19 files changed, 309 insertions(+), 19 deletions(-)
 create mode 100644 src/Statistics.cpp
 create mode 100644 src/Statistics.h

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index e95d0edcc8..2def274a79 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -56,7 +56,7 @@
 #include "PDFOptions.h"
 #include "Session.h"
 #include "SpellChecker.h"
-#include "xml.h"
+#include "Statistics.h"
 #include "texstream.h"
 #include "TexRow.h"
 #include "Text.h"
@@ -66,6 +66,7 @@
 #include "VCBackend.h"
 #include "version.h"
 #include "WordLangTuple.h"
+#include "xml.h"
 
 #include "insets/InsetBranch.h"
 #include "insets/InsetInclude.h"
@@ -357,6 +358,9 @@ public:
 	///
 	mutable bool need_update;
 
+	///
+	Statistics statistics_;
+
 private:
 	int word_count_;
 	int char_count_;
@@ -5544,6 +5548,12 @@ int Buffer::charCount(bool with_blanks) const
 }
 
 
+Statistics & Buffer::statistics()
+{
+	return d->statistics_;
+}
+
+
 bool Buffer::areChangesPresent() const
 {
 	return inset().isChanged();
diff --git a/src/Buffer.h b/src/Buffer.h
index d9e7e325d4..17a8fbbc87 100644
--- a/src/Buffer.h
+++ b/src/Buffer.h
@@ -51,6 +51,7 @@ class otexstream;
 class ParagraphList;
 class ParIterator;
 class ParConstIterator;
+class Statistics;
 class TeXErrors;
 class TexRow;
 class TocBackend;
@@ -793,6 +794,7 @@ public:
 	/// statistics accessor functions
 	int wordCount() const;
 	int charCount(bool with_blanks) const;
+	Statistics & statistics();
 
 	///
 	bool areChangesPresent() const;
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index ce315a6f49..cfce928da2 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -38,6 +38,7 @@
 #include "MetricsInfo.h"
 #include "Paragraph.h"
 #include "Session.h"
+#include "Statistics.h"
 #include "texstream.h"
 #include "Text.h"
 #include "TextMetrics.h"
@@ -78,6 +79,7 @@
 #include "support/Lexer.h"
 #include "support/lstrings.h"
 #include "support/lyxlib.h"
+#include "support/pmprof.h"
 #include "support/types.h"
 
 #include 
@@ -2014,6 +2016,7 @@ void BufferView::dispatch(FuncRequest const & cmd, DispatchResult & dr)
 			f

[LyX/master] Store spellchecker_esc_chars as a docstring

2024-07-21 Thread Jean-Marc Lasgouttes

commit 23379bb1d596359a0922b9d14e6f83c003ecd14d
Author: Jean-Marc Lasgouttes 
Date:   Sun Jul 21 21:33:01 2024 +0200

Store spellchecker_esc_chars as a docstring

This is a minor optimization to avoid calling from_utf8() repeatedly
on a hot path.
---
 src/LyXRC.cpp | 2 +-
 src/LyXRC.h   | 2 +-
 src/Paragraph.cpp | 4 ++--
 src/frontends/qt/GuiPrefs.cpp | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/LyXRC.cpp b/src/LyXRC.cpp
index fb9eb8f303..ce0d4ee92a 100644
--- a/src/LyXRC.cpp
+++ b/src/LyXRC.cpp
@@ -2419,7 +2419,7 @@ void LyXRC::write(ostream & os, bool ignore_system_lyxrc, 
string const & name) c
case RC_ESC_CHARS:
if (ignore_system_lyxrc ||
spellchecker_esc_chars != 
system_lyxrc.spellchecker_esc_chars) {
-   os << "\\escape_chars \"" << spellchecker_esc_chars << 
"\"\n";
+   os << "\\escape_chars \"" << 
to_utf8(spellchecker_esc_chars) << "\"\n";
}
if (tag != RC_LAST)
break;
diff --git a/src/LyXRC.h b/src/LyXRC.h
index e0c2da3178..a8b4b04452 100644
--- a/src/LyXRC.h
+++ b/src/LyXRC.h
@@ -372,7 +372,7 @@ public:
/// Alternate language for spellchecker
std::string spellchecker_alt_lang;
/// Escape characters
-   std::string spellchecker_esc_chars;
+   docstring spellchecker_esc_chars;
/// Accept compound words in spellchecker?
bool spellchecker_accept_compound = false;
/// spellcheck continuously?
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index 369d03ee83..d21e86ebbf 100644
--- a/src/Paragraph.cpp
+++ b/src/Paragraph.cpp
@@ -4275,8 +4275,8 @@ bool Paragraph::isWordSeparator(pos_type pos, bool const 
ignore_deleted) const
return false;
char_type const c = d->text_[pos];
// We want to pass the escape chars to the spellchecker
-   docstring const escape_chars = from_utf8(lyxrc.spellchecker_esc_chars);
-   return !isLetterChar(c) && !isDigitASCII(c) && !contains(escape_chars, 
c);
+   return !isLetterChar(c) && !isDigitASCII(c)
+  && !contains(lyxrc.spellchecker_esc_chars, c);
 }
 
 
diff --git a/src/frontends/qt/GuiPrefs.cpp b/src/frontends/qt/GuiPrefs.cpp
index 230d377a2b..6eac7d9fab 100644
--- a/src/frontends/qt/GuiPrefs.cpp
+++ b/src/frontends/qt/GuiPrefs.cpp
@@ -1515,7 +1515,7 @@ void PrefSpellchecker::applyRC(LyXRC & rc) const
if (!speller.empty())
rc.spellchecker = speller;
rc.spellchecker_alt_lang = fromqstr(altLanguageED->text());
-   rc.spellchecker_esc_chars = fromqstr(escapeCharactersED->text());
+   rc.spellchecker_esc_chars = qstring_to_ucs4(escapeCharactersED->text());
rc.spellchecker_accept_compound = compoundWordCB->isChecked();
rc.spellcheck_continuously = spellcheckContinuouslyCB->isChecked();
rc.spellcheck_notes = spellcheckNotesCB->isChecked();
-- 
lyx-cvs mailing list
lyx-cvs@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-cvs

[RCU] Re: Multiple domains config

2024-07-21 Thread Marc

> 
> I use the latest version of roundcube as my webmail, and I want to allow
> webmail access to free.fr and gmx.it (I have accounts with these two
> email providers).So set the following in rc's configuration file.
> 
> $config['imap_host'] =
> array('ssl://imap.gmx.com:993','ssl://imap.free.fr:993');
> 
> $config['smtp_host'] = array('imap.gmx.com' => 'ssl://mail.gmx.com:465',
>  'imap.free.fr' => 'ssl://smtp.free.fr:465'
>);
> 
> $config['mail_domain'] = array(
>   'imap.gmx.com' => 'gmx.it',
>   'imap.free.fr' => 'free.fr'
> );
> 
> 
> When I open webmail, it always displays a dropdown menu for me to select
> an IMAP host. This is so frustrating. How to disable this drop-down menu
> and automatically match email addresses to imap hosts?
> 

I guess the info in the "Re: smtp servers" thread will help you further.



___
Users mailing list -- users@lists.roundcube.net
To unsubscribe send an email to users-le...@lists.roundcube.net

Re: Scrolling unresponsive in LyX 2.4.0

2024-07-21 Thread Jean-Marc Lasgouttes


Le 21/07/2024 à 05:04, Richard Kimberly Heck a écrit :
Hmm. It did not occur to me when adding that that this might show up in 
the status bar. Maybe it didn't then? Anyway, I should have a look at 
some point.


I plan to give a go at a rewrite of the stat gathering code today, to 
see how fast it can get.


JMarc
--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Re: guile-devel Digest, Vol 260, Issue 25

2024-07-21 Thread Marc Nieper-Wißkirchen

 is needed is a well-known name
(well-known for those who have browsed which libraries are available) that
is sufficiently unique. Introducing a new name can be counterproductive as
it reduces the name recognition of the old name (which will still be
around). Moreover, it introduces friction: programmers who study existing
code will have to know both the old name and the new alias, making things
more complicated in the end. Unless there is a technical benefit to doing
so, I advise against replacing "ice-9" with "guile". Another reason for my
wariness is that not everything in the ice-9 namespace is Guile-specific in
the strict sense. For example, (ice-9 regex) seems to be a library that can
live outside of Guile's universe as well. Finally, talking about "ice-9"
(or even about names like "define-module2") feels like bikeshedding.

Cheers,

Marc

Am Sa., 20. Juli 2024 um 22:35 Uhr schrieb :

> Send guile-devel mailing list submissions to
> guile-devel@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/guile-devel
> or, via email, send a message with subject or body 'help' to
> guile-devel-requ...@gnu.org
>
> You can reach the person managing the list at
> guile-devel-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of guile-devel digest..."
>
>
> Today's Topics:
>
>1. Portable imports (Lassi Kortela)
>2. RE: Portable imports (Maxime Devos)
>3. RE: Portable imports (Maxime Devos)
>4. Encoding library names (Lassi Kortela)
>5. RE: Encoding library names (Maxime Devos)
>
>
> --
>
> Message: 1
> Date: Sat, 20 Jul 2024 21:42:37 +0300
> From: Lassi Kortela 
> To: Maxime Devos , "Dr. Arne Babenhauserheide"
> 
> Cc: Attila Lendvai , Greg Troxel
> , MSavoritias ,
> "guile-devel@gnu.org" 
> Subject: Portable imports
> Message-ID: <04293f0f-3a83-4ebc-8413-1a936caae...@lassi.io>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> > I don’t know if ‘(import ...)’ is standard either (sure it is as part of
> > ‘define-library’, but I didn’t find it on its own in r7rs.pdf),
>
> (import ...) is standard in both R6RS and R7RS, and supported by every
> serious implementation of those standards. Please spread it.
>
> R7RS talks about "programs" and "libraries". These are technical terms
> with precise meanings.
>
> A "program" corresponds to your typical Scheme script. IIRC it _has_ to
> start with (import ...).
>
> A "library" is a (library ...) [in R6RS] or a (define-library ...) [in
> R7RS]. You can type (import ...) inside either.
>
> >  > https://srfi.schemers.org/srfi-97/srfi-97.html:
> >
> >  >A SRFI Library can be referenced by number, as in
> >
> >  >(srfi :1),
> >
> > (srfi 1) is problematic, since ‘1’ is not an symbol (#{1}# is, but
> > that’s not what has been choosen in SRFI 97).
>
> In R7RS non-negative integers can be library name parts. Since these
> library names look natural, it would be good to backport this to R6RS
> implementations.
>
> The colon causes endless grief when mapping library names to file names.
> For example, look at all the %3a in
> https://github.com/arcfide/chez-srfi. That's not even the worst of it.
>
>
>
> --
>
> Message: 2
> Date: Sat, 20 Jul 2024 21:18:53 +0200
> From: Maxime Devos 
> To: Lassi Kortela ,  "Dr. Arne Babenhauserheide"
> 
> Cc: Attila Lendvai , Greg Troxel
> ,  MSavoritias ,
> "guile-devel@gnu.org" 
> Subject: RE: Portable imports
> Message-ID:
> <20240720211840.pvjf2c00709gymg06vj...@michel.telenet-ops.be>
> Content-Type: text/plain; charset="utf-8"
>
> >In R7RS non-negative integers can be library name parts. Since these
> library names look natural, it would be good to backport this to R6RS
> implementations.
>
> Then (library [...] (import (srfi 1)) [...]) would work, and since
> ‘library’ is (R6RS) standard and reasonably portable it would then appear
> that (srfi 1) is (R6RS) standard and portable, whereas it isn’t R6RS, and
> hence not a good idea to backport.
>
> >The colon causes endless grief when mapping library names to file names.
> >For example, look at all the %3a in
> https://github.com/arcfide/chez-srfi. That's not even the worst of it.
>
> I don’t think this is a problem for Guile? I don’t recall to what extent,
&g

Re: Scrolling unresponsive in LyX 2.4.0

2024-07-20 Thread Jean-Marc Lasgouttes


Le 16/07/2024 à 00:13, Hung-Tzu Chang a écrit :
Here are the files. The file named "scroll-problem" means problem with 
scrolling/frozen citation window/frozen menu bar, etc.


Thanks!


Dear Hung-Tzu,

Thanks for the files. I can confirm that I observe hangs when scrolling 
with LyX 2.4.1 and that the performance is much much better with current 
2.4.2~devel.


Running under a profiler reveals that the problem is related to the 
word-counting function in status bar; this triggers every few seconds 
and generate the label of citation insets in order to count words in there.


So the good news is that these "hang" events should disappear if you 
disable this feature by right-clicking the status bar.


Hope this helps,
Jean-Marc
--
lyx-users mailing list
lyx-users@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-users

Get rid of INSTALL.MacOSX?

2024-07-20 Thread Jean-Marc Lasgouttes

The last remaining bit of TODO.killqt4 is INSTALL.MacOSX. I thought we 
wanted to update it, but I fail to see what should be kept in this file 
as it is.


Stephan, do we have a reason to keep it?

Later, you could create a new INSTALL.macOS with up-to-date information 
if you feel that the file is needed.


Thoughts?

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

< 5 6 7 8 9 10 11 12 13 14 >

901 - 1000 of 41237 matches

Mail list logo