from:"thomas"


On Monday, October 28, 2024 at 3:20:40 AM UTC-4 viktor@gmail.com wrote:

I tried to do a re-rest of the latest changes - and - noticed that there is 
a surprising interaction b/w the ~ final ~ layout system implementation & 
the help system.

*NO help info is not displayed at all until I explicitly performed a 
'layout-restore-to-settings' !*


Checking the behavior on my system, the help system does make VR3 visible 
when used right after startup.  Specifically, with the initial layout set 
to "vertical-thirds", F11 opens VR3 before showing the help  and the "Help" 
menu items also display in VR3.

You mentioned a "fresh" installation.  Would you explain more detail about 
the case where Help did not display?

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/e6adeeae-819c-49a5-b1ce-a580a60f2ce7n%40googlegroups.com.

Re: Fixed: Leo's help-for-layouts command

It seems that the "qt-style-name" is indeed meant for something other than 
layouts, possibly the window "look and feel".  If that's right, it's a good 
name for the setting IMO.  I thought from Viktor's post that 
qt-style-name"  had replaced "qt-layout-name" but it hasn't.

On Monday, October 28, 2024 at 8:27:27 AM UTC-4 viktor@gmail.com wrote:

> Hello Edward,
>
> Edward K. Ream schrieb am Montag, 28. Oktober 2024 um 12:45:00 UTC+1:
>
> On Mon, Oct 28, 2024 at 6:29 AM Thomas Passin  wrote:
>
> The problem is that we don't activate VR/VR3 at first because the user 
> might not want to see it and it's pretty distracting when you don't want 
> it. Until the first time VR3 is shown in a layout, it's quiescent. The same 
> thing probably happens for the F11 command.  I thought I had checked all 
> the combinations but apparently not.  I'll work out how to make it work as 
> intended.  VR works a little differently so when VR3 is not enabled I think 
> that Help does show initially.
>
>
> Thanks for looking into this.
>
>
> About the settings, the last I looked, the setting in LeoSettings.leo was 
> for "legacy". I didn't know it had been changed. I also didn't know the 
> name of the setting had changed.  Grrr. I don't like this new name because 
> "style" could mean many things but "layout" is more specific. 
>
>
> Thomas, *please, please, please* be more specific. I have to assume that 
> by "the setting" you mean:
>
> @string qt-layout-name = legacy
>
>
> In my initial reply to both of you, I had documented my finding, that in a 
> recent change by you (Edward?) the setting that Thomas had originally used 
> - and - which I had still saved in "myLeoSettings.leo" was changed :
>
>- From  '"@string qt-*layout*-name = None" to '"@string qt-*style*-name 
>= None" !
>
> I hope this clears up the confusion.
>
> With kind regards,
>
> Viktor
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/088aa5db-0eef-4a9f-872b-afebdd06748an%40googlegroups.com.

Re: Fixed: Leo's help-for-layouts command

I was responding to Viktor's post just before mine:

"When I looked further into it I found out that in "myLeoSeetings.leo" I'm
still using

- @string qt-*layout*-name = vertical-thirds # Qt Gui settings ...

while in "leoSettings.leo" it has been (recently?) renamed to

- @string qt-*style*-name = None # Qt Gui settings"

I see I should have quoted more from the post.

On Monday, October 28, 2024 at 7:45:00 AM UTC-4 Edward K. Ream wrote:

On Mon, Oct 28, 2024 at 6:29 AM Thomas Passin wrote:

The problem is that we don't activate VR/VR3 at first because the user
might not want to see it and it's pretty distracting when you don't want
it. Until the first time VR3 is shown in a layout, it's quiescent. The same
thing probably happens for the F11 command. I thought I had checked all
the combinations but apparently not. I'll work out how to make it work as
intended. VR works a little differently so when VR3 is not enabled I think
that Help does show initially.

Thanks for looking into this.

About the settings, the last I looked, the setting in LeoSettings.leo was
for "legacy". I didn't know it had been changed. I also didn't know the
name of the setting had changed. Grrr. I don't like this new name because
"style" could mean many things but "layout" is more specific.

Thomas, *please, please, please* be more specific. I have to assume that by
"the setting" you mean:

@string qt-layout-name = legacy

Otherwise, I have no idea to what setting you are referring.

Edward

--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/leo-editor/9197c269-2796-4afd-89fe-b2696b9dd4c7n%40googlegroups.com.

[NTG-context] Re: using command line arguments

2024-10-28 Thread Thomas A. Schmitz


On 28.10.24 12:18, Henning Hraban Ramm wrote:
Hi, I’m trying to use a command line argument in parameter names – color 
name in the example below, variable namespace in my actual project.

I guess I need more expansion, but where?
Or what’s the problem here?


Perhaps my approach is too simplistic, but if I had to do something like 
that, I would use modes:


\startmode [fiee]
  \definecolor [OEM] [c=1]
  \def{OEM}{fiee}
\stopmode

and for the fallback, use

\startnotallmodes [...]

then you can call from the command line with --mode=fiee and write

\color[OEM]{Company: \OEM}

But maybe your needs are more complex...

All best

Thomas
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

30.000 FAIme jobs created in 7 years

2024-10-28 Thread Thomas Lange

Here's a blog post about the FAIme service that created its 30.000th job.

https://blog.fai-project.org/posts/faime-3/

-- 
best regards Thomas

Re: Fixed: Leo's help-for-layouts command

The problem is that we don't activate VR/VR3 at first because the user 
might not want to see it and it's pretty distracting when you don't want 
it. Until the first time VR3 is shown in a layout, it's quiescent. The same 
thing probably happens for the F11 command.  I thought I had checked all 
the combinations but apparently not.  I'll work out how to make it work as 
intended.  VR works a little differently so when VR3 is not enabled I think 
that Help does show initially.

About the settings, the last I looked, the setting in LeoSettings.leo was 
for "legacy". I didn't know it had been changed. I also didn't know the 
name of the setting had changed.  Grrr. I don't like this new name because 
"style" could mean many things but "layout" is more specific. "Style" tends 
to be used more for things like color, font, etc. I want setting's name 
changed back, or to something else with "layout" in its name.  The name 
"qt-layout-name" was good because it only applies for the Qt GUI, it's 
about layouts, and specifically it's the actual name of the layout you 
want.  The new name is not about layouts any more so I don't like it.

On Monday, October 28, 2024 at 3:20:40 AM UTC-4 viktor@gmail.com wrote:

> Hello Edward, hello Thomas,
>
> Edward K. Ream schrieb am Samstag, 26. Oktober 2024 um 13:36:51 UTC+2:
>
> On Saturday, October 26, 2024 at 2:05:12 AM UTC-5 Edward K. Ream wrote:
>
> PR #4129 <https://github.com/leo-editor/leo-editor/pull/4129> fixes the 
> help-for-layouts command and improves the text of several docstrings.
>
>
> There were some ruffled features between Thomas and myself yesterday. 
> Sometimes that happens even in the best collaborations. What matters is 
> that the result is much better than what either of us would have done 
> separately. The PR acknowledges Thomas's crucial insight: synthesizing the 
> text of the help-for-layouts and show-layouts commands from the docstrings 
> of the commands themselves.
>
>
> I tried to do a re-rest of the latest changes - and - noticed that there 
> is a surprising interaction b/w the ~ final ~ layout system implementation 
> & the help system.
>
> *NO help info is not displayed at all until I explicitly performed a 
> 'layout-restore-to-settings' !*
>
> This behavior does not show up - IF - you test in a ~ fresh ~ 
> installation, because for the new user the 'legacy / none' setting is 
> pre-configured in "leoSettings.leo".
>
> When I looked further into it I found out that in "myLeoSeetings.leo" I'm 
> still using
>
>- @string qt-*layout*-name = vertical-thirds # Qt Gui settings ...
>
> while in "leoSettings.leo" it has been (recently?) renamed to
>
>- @string qt-*style*-name = None # Qt Gui settings
>
> Are both of you aware of that situation ?
>
> With kind regards,
>
> Viktor
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/96603c18-d8ce-4cdf-a3da-1e6641bed09fn%40googlegroups.com.

Re: Jupytext - Script To Split Into Child Nodes


On Monday, October 28, 2024 at 5:00:23 AM UTC-4 Edward K. Ream wrote:

On Sun, Oct 27, 2024 at 4:21 PM Thomas Passin  wrote:

Here is a script that will take an @jupytext tree and split it out into 
child nodes, one node per cell.  To use, make a script button for it, 
select a @jupytext node, and run the script.  The script tries to create 
reasonable headlines for the nodes but of course it can't be perfect.


This script, with undo, deserves to be a Leo command. If you like, please 
submit a PR. I'll be happy to provide advice.


I would for sure like help with the undo.  Also, I think this command 
should be made part of the import process. If there ever turns out to be a 
need for someone to look at the original flat jupytext node there could be 
another command for that.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/8086128a-c79e-4027-9995-95299ea901fbn%40googlegroups.com.

Re: Jupytext - Script To Split Into Child Nodes


On Monday, October 28, 2024 at 3:43:23 AM UTC-4 iamap...@gmail.com wrote:

Thanks Thomas, It works great!

Although for `jupyter lab`, its ToC is displayed according to the markdown 
level in the document, I think it is not a big problem to extract nodes 
according to cells like you did, anyway, nodes are easy to operate in Leo.


I wasn't sure if levels of indentation were meaningful in Jupyter notebooks 
so I didn't handle them at this early stage.  It won't be much harder to 
include them.

Another feature that's sorely needed and easy to add is to put an 
"@nocolor" directive in markdown cells.  Since all non-code lines in a 
jupytext file are comments, they get colored by Leo's colorizer and for 
many if not most themes they are hard to read - not what one wants for 
pleasant editing.

So stay tuned ...
 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/a9958b72-14fb-48e5-930e-c592d6af932dn%40googlegroups.com.

[Bug 2085763] [NEW] routers.py not compatible with Python 3.12

2024-10-28 Thread Thomas Hoffmann

Public bug reported:

Ubuntu 24.04 LTS ships with Pythn 3.12.
However, the included graphite-carbon package (version 1.1.7-1.1) is not 
compatible with Python 3.12.
The service fails to start because router.py is including the package imp which 
is not available any more.

>service carbon-cache status
shows the error message:
carbon-cache[1581]: ModuleNotFoundError: No module named 'imp'

Python 3.12 support was added with this commit:
https://github.com/graphite-project/carbon/pull/951/commits/dea2ddb038b01eff16f5da4a19c7282e438ec19a

The error can be reproduced by just installing graphite-carbon:
apt-get install graphite-carbon

Is it possible to update the graphite-carbon package in order to work
with Python 3.12 or to add the fixes to the Ubuntu package?

** Affects: graphite-carbon (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  routers.py not compatible with Python 3.12

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/graphite-carbon/+bug/2085763/+subscriptions


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

[jira] [Created] (CAMEL-21392) Add support for --cluster-type=k3s

2024-10-28 Thread Thomas Diesler (Jira)

Thomas Diesler created CAMEL-21392:
--

 Summary: Add support for --cluster-type=k3s
 Key: CAMEL-21392
 URL: https://issues.apache.org/jira/browse/CAMEL-21392
 Project: Camel
  Issue Type: New Feature
  Components: camel-jbang
Reporter: Thomas Diesler
Assignee: Thomas Diesler


K3S is a popular Kubernetes distribution built for IoT & Edge computing.
https://k3s.io



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[tmux/tmux] 125a7b: Fix issues in the command prompt: set PROMPT_QUOTE...

2024-10-28 Thread &#x27;Thomas Adam' via tmux-git

  Branch: refs/heads/master
  Home:   https://github.com/tmux/tmux
  Commit: 125a7b91776a02d3ba391bbcdaf571cbbe2a33f2
  
https://github.com/tmux/tmux/commit/125a7b91776a02d3ba391bbcdaf571cbbe2a33f2
  Author: nicm 
  Date:   2024-10-28 (Mon, 28 Oct 2024)

  Changed paths:
M status.c

  Log Message:
  ---
  Fix issues in the command prompt: set PROMPT_QUOTENEXT after quoting
than before, meaning that accidentally scrolling the mouse wheel doesn't
break quoting; and move the cursor correctly over wide characters. From
Alexander Arch in GitHub issue 4212.


  Commit: 62e15e905bda23de4aafca6c3f9bc08ebe2326a1
  
https://github.com/tmux/tmux/commit/62e15e905bda23de4aafca6c3f9bc08ebe2326a1
  Author: nicm 
  Date:   2024-10-28 (Mon, 28 Oct 2024)

  Changed paths:
M format.c

  Log Message:
  ---
  Treat tabs as a word separator, from Alexander Arch in GitHub issue
4201.


  Commit: c8bd42de160902a3efebf021b660fd230ca08ca2
  
https://github.com/tmux/tmux/commit/c8bd42de160902a3efebf021b660fd230ca08ca2
  Author: nicm 
  Date:   2024-10-28 (Mon, 28 Oct 2024)

  Changed paths:
M window-copy.c

  Log Message:
  ---
  Match tab cells when searching, from Alexander Arch in GitHub issue
4201.


  Commit: bbc3cc558c642834e0ba20dd124f0f124217ad5f
  
https://github.com/tmux/tmux/commit/bbc3cc558c642834e0ba20dd124f0f124217ad5f
  Author: Thomas Adam 
  Date:   2024-10-28 (Mon, 28 Oct 2024)

  Changed paths:
M format.c
M status.c
M window-copy.c

  Log Message:
  ---
  Merge branch 'obsd-master'


Compare: https://github.com/tmux/tmux/compare/895044c52b6b...bbc3cc558c64

To unsubscribe from these emails, change your notification settings at 
https://github.com/tmux/tmux/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"tmux-git" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tmux-git+unsubscr...@googlegroups.com.
To view this discussion, visit 
https://groups.google.com/d/msgid/tmux-git/tmux/tmux/push/refs/heads/master/895044-bbc3cc%40github.com.

Re: [blink-dev] Intent to Ship: File System Access on Android and WebView

2024-10-28 Thread &#x27;Thomas Steiner' via blink-dev

Wow, that's fantastic news!

I tried the feature on 132.0.6803.0 on Android VanillaIceCream with this
demo <https://googlechromelabs.github.io/browser-fs-access/demo/> that uses
the main window, a same origin iframe, and a cross origin iframe (the last
one should not work).

   - Opening a single file and multiple files works just fine. A slight
   user irritation was the camera and microphone permission, but it made sense
   once I saw the picker, which is a camera and the files icons.
   - File MIME type filters seem to be ignored. I filtered on images and
   texts, but could open a PDF.
   - Opening folders works just fine. You need to be careful to not open a
   too big folder. Attempting to open DCIM caused Canary to become
   unresponsive.
   - Saving seems to not work quite yet. While it did trigger the same
   picker with the files and the camera icons (the camera should probably not
   be there, it should just enter the files flow directly), there was in the
   end no obvious way for me to say "yes, save here", that is, some sort of
   file name dialog. Did I not understand what I needed to do?

Amazing work. I suppose the rest is polish and already known issues.

Cheers,
Tom


On Sat, Oct 26, 2024 at 1:06 AM Joel Hockey  wrote:

> The FileSystemAccessLocal feature has just been enabled for android in
> M132.
>
> On Thu, Sep 5, 2024 at 7:30 PM Thomas Steiner  wrote:
>
>> Very excited for this feature to come, it's a frequently requested gap so
>> far—frequently enough to link to the FSA for Android bug from our
>> developer-facing documentation
>> <https://developer.chrome.com/docs/capabilities/web-apis/file-system-access#:~:text=Support%20for%20Android%20is%20being%20worked%20on%20in%20the%20context%20of%20crbug.com/1011535.>
>> .
>>
>>
>>> There is one area where I am considering proposing a change to the spec
>>> that showOpenFilePicker() could take a boolean hint to indicate the
>>> intention of whether files are intended for read-only vs writable which
>>> would allow Android to choose between Intent GET_CONTENT (read-only, but
>>> supported by more providers) vs OPEN_DOCUMENT (allows for writing to files,
>>> but not supported by as many providers).
>>>
>>
>> I've just commented on a relevant GitHub issue
>> <https://github.com/WICG/file-system-access/issues/302#issuecomment-2331041290>
>>  and
>> tagged you.
>>
>

-- 
Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com,
toot.cafe/@tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

- BEGIN PGP SIGNATURE -
Version: GnuPG v2.4.3 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck
0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181.
- END PGP SIGNATURE -

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALgRrL%3D05USBgLCdEgg3k9bcxB%2BzU3YXpXU9i8egymV3KJLQbA%40mail.gmail.com.

Re: [PATCH] fbdev: udl: Make CONFIG_FB_DEVICE optional

2024-10-28 Thread Thomas Zimmermann


Hi Helge

Am 25.10.24 um 17:37 schrieb Helge Deller:

On 10/25/24 11:25, Gonzalo Silvalde Blanco wrote:

The fb_udl driver currently depends on CONFIG_FB_DEVICE to create sysfs
entries and access framebuffer device information. This patch wraps the
relevant code blocks with #ifdef CONFIG_FB_DEVICE, allowing the 
driver to

be built and used even if CONFIG_FB_DEVICE is not selected.

The sysfs setting only controls access to certain framebuffer attributes
and is not required for the basic display functionality to work 
correctly.

(For information on DisplayLink devices and their Linux support, see:
https://wiki.archlinux.org/title/DisplayLink).

Tested by building with and without CONFIG_FB_DEVICE, both of which
compiled and ran without issues.


Gonzalo, I don't like this patch very much.

It adds lots of #ifdefs around functions like dev_dbg().
Instead of ifdefs, aren't there other possibilities, e.g.
using fb_dbg() if appropriate?
Or using any other generic dbg() info or simply dropping the line?


I talked Gonzalo into sending this patch. I think dev_dbg() calls should 
be replaced with fb_dbg(), same for _info() and _err(). That's probably 
worth doing anyway.




But more important:
This is a fbdev driver and currently depends on CONFIG_FB_DEVICE.
If I'm right, the only reason to disable CONFIG_FB_DEVICE is if
you want fbdev output at bootup, but otherwise just want to use DRM.


It's unrelated to booting. CONFIG_FB_DEVICE enables/disables userspace 
interfaces (/dev/fb*, /sys/graphics/fb*). Even without, there's still 
fbcon that runs on top of the fbdev driver.



But then, doesn't there exist a native DRM driver for this graphics
card which can be used instead?
If so, I suggest to not change this fbdev driver at all.


Or can we talk about removing udlfb entirely? I tried before, but there 
was one person still using it. [1] He had concerns about udl's (the DRM 
driver) stability. I think DRM's udl has matured enough and is in better 
shape than udlfb. Maybe we can try again.


[1] 
https://lore.kernel.org/dri-devel/20201130125200.10416-1-tzimmerm...@suse.de/


Best regards
Thomas



Helge


Signed-off-by: Gonzalo Silvalde Blanco > ---
  drivers/video/fbdev/Kconfig |  1 -
  drivers/video/fbdev/udlfb.c | 41 ++---
  2 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index ea36c6956bf3..9bf6cf74b9cb 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1588,7 +1588,6 @@ config FB_SMSCUFX
  config FB_UDL
  tristate "Displaylink USB Framebuffer support"
  depends on FB && USB
-    depends on FB_DEVICE
  select FB_MODE_HELPERS
  select FB_SYSMEM_HELPERS_DEFERRED
  help
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 71ac9e36f67c..de4800f09dc7 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -341,10 +341,10 @@ static int dlfb_ops_mmap(struct fb_info *info, 
struct vm_area_struct *vma)

  return -EINVAL;

  pos = (unsigned long)info->fix.smem_start + offset;
-
+#ifdef CONFIG_FB_DEVICE
  dev_dbg(info->dev, "mmap() framebuffer addr:%lu size:%lu\n",
  pos, size);
-
+#endif
  while (size > 0) {
  page = vmalloc_to_pfn((void *)pos);
  if (remap_pfn_range(vma, start, page, PAGE_SIZE, PAGE_SHARED))
@@ -929,10 +929,10 @@ static int dlfb_ops_open(struct fb_info *info, 
int user)

  info->fbdefio = fbdefio;
  fb_deferred_io_init(info);
  }
-
+#ifdef CONFIG_FB_DEVICE
  dev_dbg(info->dev, "open, user=%d fb_info=%p count=%d\n",
  user, info, dlfb->fb_count);
-
+#endif
  return 0;
  }

@@ -982,9 +982,9 @@ static int dlfb_ops_release(struct fb_info *info, 
int user)

  kfree(info->fbdefio);
  info->fbdefio = NULL;
  }
-
+#ifdef CONFIG_FB_DEVICE
  dev_dbg(info->dev, "release, user=%d count=%d\n", user, 
dlfb->fb_count);

-
+#endif
  return 0;
  }

@@ -1095,10 +1095,10 @@ static int dlfb_ops_blank(int blank_mode, 
struct fb_info *info)

  struct dlfb_data *dlfb = info->par;
  char *bufptr;
  struct urb *urb;
-
+#ifdef CONFIG_FB_DEVICE
  dev_dbg(info->dev, "blank, mode %d --> %d\n",
  dlfb->blank_mode, blank_mode);
-
+#endif
  if ((dlfb->blank_mode == FB_BLANK_POWERDOWN) &&
  (blank_mode != FB_BLANK_POWERDOWN)) {

@@ -1190,7 +1190,9 @@ static int dlfb_realloc_framebuffer(struct 
dlfb_data *dlfb, struct fb_info *info

   */
  new_fb = vmalloc(new_len);
  if (!new_fb) {
+#ifdef CONFIG_FB_DEVICE
  dev_err(info->dev, "Virtual framebuffer alloc failed\n");
+#endif
  return -ENOMEM;
  }
  memset(new_fb, 0xff, new_len);
@@ -1213,9 +1215,11

[kmymoney] [Bug 488491] Make 5.2 release

2024-10-28 Thread Thomas Baumgart via KMyMoney-devel

https://bugs.kde.org/show_bug.cgi?id=488491
Bug 488491 depends on bug 495417, which changed state.

Bug 495417 Summary: Currency conversion in category/accounts view is not correct
https://bugs.kde.org/show_bug.cgi?id=495417

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 495417] Currency conversion in category/accounts view is not correct

2024-10-28 Thread Thomas Baumgart

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

Thomas Baumgart  changed:

   What|Removed |Added

   Version Fixed In||5.2
 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED
  Latest Commit||https://invent.kde.org/offi
   ||ce/kmymoney/-/commit/a09349
   ||e3c4982c042774087e334ae324f
   ||2cff6e0

--- Comment #1 from Thomas Baumgart  ---
Git commit a09349e3c4982c042774087e334ae324f2cff6e0 by Thomas Baumgart.
Committed on 28/10/2024 at 07:42.
Pushed by tbaumgart into branch 'master'.

Remove unnecessary conversion from denominator to precision
FIXED-IN: 5.2

M  +1-1kmymoney/mymoney/storage/accountsmodel.cpp

https://invent.kde.org/office/kmymoney/-/commit/a09349e3c4982c042774087e334ae324f2cff6e0

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

[kmymoney] [Bug 488491] Make 5.2 release

2024-10-28 Thread Thomas Baumgart

https://bugs.kde.org/show_bug.cgi?id=488491
Bug 488491 depends on bug 495417, which changed state.

Bug 495417 Summary: Currency conversion in category/accounts view is not correct
https://bugs.kde.org/show_bug.cgi?id=495417

   What|Removed |Added

 Status|REPORTED|RESOLVED
 Resolution|--- |FIXED

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

[kmymoney] [Bug 495417] Currency conversion in category/accounts view is not correct

2024-10-28 Thread Thomas Baumgart via KMyMoney-devel

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

Thomas Baumgart  changed:

   What|Removed |Added

   Version Fixed In||5.2
 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED
  Latest Commit||https://invent.kde.org/offi
   ||ce/kmymoney/-/commit/a09349
   ||e3c4982c042774087e334ae324f
   ||2cff6e0

--- Comment #1 from Thomas Baumgart  ---
Git commit a09349e3c4982c042774087e334ae324f2cff6e0 by Thomas Baumgart.
Committed on 28/10/2024 at 07:42.
Pushed by tbaumgart into branch 'master'.

Remove unnecessary conversion from denominator to precision
FIXED-IN: 5.2

M  +1-1kmymoney/mymoney/storage/accountsmodel.cpp

https://invent.kde.org/office/kmymoney/-/commit/a09349e3c4982c042774087e334ae324f2cff6e0

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [Bacula-devel] Build fails with LTO due to ODR violations

2024-10-28 Thread Thomas Beierlein

Hi,

On Sun, Oct 27, 2024 at 03:48:54PM +0100, Radosław Korzeniewski wrote:
> Hi,
> 
> pt., 25 paź 2024 o 13:35 Thomas Beierlein  napisał(a):
> 
> > Hello,
> >
> > building bacula-15.0.2 here on Gentoo with
> > '-Werror=lto-type-mismatch -Werror=strict-aliasing -Werror=odr -flto'
> > failes with the following error:
> >
>> .
> 
> JCR is handcrafted differently for every component (#ifdef DIRECTOR_DAEMON,
> #ifdef FILE_DAEMON, #ifdef STORAGE_DAEMON) having a common part at the
> beginning of the struct.
> Looks like file daemon compilation is not separated enough from other
> component builds.

Have not check completely but a first look shows some problems with
include order - first jcr.h directly followed by filed.h which includes
jcr.h but with FILE_DAEMON set before.
> 
> 
> >
> > See https://bugs.gentoo.org/940695 for original bug and
> > https://940695.bugs.gentoo.org/attachment.cgi?id=904745 for full
> > build log.
> >
> >
> Any chance you can report this bug at: https://gitlab.bacula.org/ ?
> 
See Issue 2734 there.

Regards,
Thomas.

-- 


___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Jupytext - Script To Split Into Child Nodes

2024-10-27 Thread Thomas Passin

Here is a script that will take an @jupytext tree and split it out into 
child nodes, one node per cell.  To use, make a script button for it, 
select a @jupytext node, and run the script.  The script tries to create 
reasonable headlines for the nodes but of course it can't be perfect.

Please try it out so we can get a sense if it's going to be a useful 
solution. WARNING: there is NO undo capability yet so ONLY TRY IT ON A COPY 
of your file.

"""Move cells into child nodes of the root of an @jupytext node."""

CELL_MARKER = '# %%'
MARKER_LEN = len(CELL_MARKER)

def get_ipynb_header(notebook):
start = notebook.find('# ---')
end = notebook.find('# ---', 1) + 4
header = notebook[start:end]
return header

# Find root = root position for file
def optional_filter(p):
return p.h.startswith('@jupytext')

def find_current_atfile(p):
for p in c.p.copy().self_and_parents():
if optional_filter(p):
return p
else:
return None

def make_headline(cell: str) -> str:
lines = cell.split('\n')
for line in lines[1:]:
line = line.replace('#', '').strip()
if not line or line.startswith('%%'):
continue
words = line.split()
n = min(6, len(words))
return ' '.join(words[:n])

root = find_current_atfile(c.p)
if root is None:
g.es(' No .ipynb tree found')
else:
contents = root.b
header = get_ipynb_header(contents)
i0 = 0
n = -1  # Number of children
while True:
i0 = contents.find(CELL_MARKER, i0)
if i0 == -1:
break
i1 = contents.find(CELL_MARKER, i0 + 1)
cell = contents[i0:i1] if i1 > -1 else contents[i0:]
n += 1
p0 = root.insertAsNthChild(n)
p0.b = cell
p0.h = make_headline(cell)
if i1 == -1:
break
i0 = i1 - MARKER_LEN
root.b = header + '\n@others'
c.redraw()

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/ccacd0b2-f53f-4af7-b423-89b1b924455cn%40googlegroups.com.

[jira] [Comment Edited] (CAMEL-21388) Camel Kubernetes plugin Auto Reload with '--dev' option is not working properly

2024-10-27 Thread Thomas Diesler (Jira)



[ 
https://issues.apache.org/jira/browse/CAMEL-21388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17893253#comment-17893253
 ] 

Thomas Diesler edited comment on CAMEL-21388 at 10/27/24 4:17 PM:
--

This is a duplicate of the linked issues. Please try again once this PR got 
merged.
https://github.com/apache/camel/pull/16091


was (Author: tdiesler):
This is a duplicate of the linked issues. Please try once this PR got merged.
https://github.com/apache/camel/pull/16091

> Camel Kubernetes plugin Auto Reload with '--dev' option is not working 
> properly
> ---
>
> Key: CAMEL-21388
> URL: https://issues.apache.org/jira/browse/CAMEL-21388
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jbang
>Affects Versions: 4.8.1, 4.9.0
> Environment: Developer Sandbox for Red Hat OpenShift
>Reporter: Dominik Jelinek
>Priority: Major
>
> Following docs at 
> [https://camel.apache.org/manual/camel-jbang-kubernetes.html#_auto_reload_with_dev_option]
> Consider this command as reproducer
>  
> {code:java}
> jbang '-Dcamel.jbang.version=4.8.1' camel@apache/camel kubernetes run 
> my-route.yaml --cluster-type=openshift --dev {code}
>  
> *The '--dev' parameter was working as expected for Camel version 4.8.0 in 
> combination with OpenShift cluster* (but it was not working for a deployment 
> into eg local Minikube cluster)
> {*}Camel 4.8.1{*}, the '--dev' stopped to work and it is failing with same 
> error as when you try with local Minikube (see error below)
>  
> {code:java}
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time:  01:35 min
> [INFO] Finished at: 2024-10-25T12:36:10+02:00
> [INFO] 
> 
> Run: kubectl get pod -l app.kubernetes.io/name=my-route
> Exception in thread "main" java.util.ServiceConfigurationError: 
> io.fabric8.kubernetes.api.model.KubernetesResource: 
> io.fabric8.kubernetes.api.model.LimitRange not a subtype
>         at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593)
>         at 
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1244)
>         at 
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
>         at 
> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
>         at 
> java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132)
>         at 
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939)
>         at 
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>         at 
> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:276)
>         at 
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>         at 
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>         at 
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>         at 
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>         at 
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:1024)
>         at 
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
>         at 
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
>         at 
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
>         at 
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
>         at 
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>         at 
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>         at 
> io.fabric8.kubernetes.internal.KubernetesDeserializer$Mapping.registerClassesFromClassLoaders(KubernetesDeserializer.java:215)
>         at 
> io.fabric8.kubernetes.internal.KubernetesDeserializer.(KubernetesDeserializer.java:90)
>         at 
> io.fabric8.kubernetes.client.utils.KubernetesSerialization.getKubernet

[jira] [Resolved] (CAMEL-21388) Camel Kubernetes plugin Auto Reload with '--dev' option is not working properly

2024-10-27 Thread Thomas Diesler (Jira)



 [ 
https://issues.apache.org/jira/browse/CAMEL-21388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Diesler resolved CAMEL-21388.

Resolution: Duplicate

This is a duplicate of the linked issues. Please try once this PR got merged.
https://github.com/apache/camel/pull/16091

> Camel Kubernetes plugin Auto Reload with '--dev' option is not working 
> properly
> ---
>
> Key: CAMEL-21388
> URL: https://issues.apache.org/jira/browse/CAMEL-21388
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jbang
>Affects Versions: 4.8.1, 4.9.0
> Environment: Developer Sandbox for Red Hat OpenShift
>Reporter: Dominik Jelinek
>Priority: Major
>
> Following docs at 
> [https://camel.apache.org/manual/camel-jbang-kubernetes.html#_auto_reload_with_dev_option]
> Consider this command as reproducer
>  
> {code:java}
> jbang '-Dcamel.jbang.version=4.8.1' camel@apache/camel kubernetes run 
> my-route.yaml --cluster-type=openshift --dev {code}
>  
> *The '--dev' parameter was working as expected for Camel version 4.8.0 in 
> combination with OpenShift cluster* (but it was not working for a deployment 
> into eg local Minikube cluster)
> {*}Camel 4.8.1{*}, the '--dev' stopped to work and it is failing with same 
> error as when you try with local Minikube (see error below)
>  
> {code:java}
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time:  01:35 min
> [INFO] Finished at: 2024-10-25T12:36:10+02:00
> [INFO] 
> 
> Run: kubectl get pod -l app.kubernetes.io/name=my-route
> Exception in thread "main" java.util.ServiceConfigurationError: 
> io.fabric8.kubernetes.api.model.KubernetesResource: 
> io.fabric8.kubernetes.api.model.LimitRange not a subtype
>         at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593)
>         at 
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1244)
>         at 
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
>         at 
> java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
>         at 
> java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
>         at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132)
>         at 
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939)
>         at 
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>         at 
> java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:276)
>         at 
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>         at 
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>         at 
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
>         at 
> java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>         at 
> java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:1024)
>         at 
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
>         at 
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
>         at 
> java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
>         at 
> java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
>         at 
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>         at 
> java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>         at 
> io.fabric8.kubernetes.internal.KubernetesDeserializer$Mapping.registerClassesFromClassLoaders(KubernetesDeserializer.java:215)
>         at 
> io.fabric8.kubernetes.internal.KubernetesDeserializer.(KubernetesDeserializer.java:90)
>         at 
> io.fabric8.kubernetes.client.utils.KubernetesSerialization.getKubernetesDeserializer(KubernetesSerialization.java:153)
>         at 
> io.fabric8.kubernetes.client.utils.KubernetesSerialization.access$000(KubernetesSerialization.java:66)
>         at 
> io.fabric8.kubernetes.client.utils.Kubern

[patch, Fortran] Introduce unsigned versions of MASKL and MASKR


Hello world,

MASKR and MASKL are obvious candidates for unsigned, too; in the
previous version of the doc patch, I had promised that these would
take unsigned arguments in the future. What I had in mind was
they could take an unsigned argument and return an unsigned result.

Thinking about this a bit more, I realized that this was actually a
bad idea; nowhere else do we allow UNSIGNED for bit counting, and things
like checking for negative number of bits (which is illegal) would not
work.

Hence, two new intrinsics, UMASKL and UMASKR.  Regressoin-tesed
(and this time, I added the intrinsics to the list, so no trouble
expected there :-)

OK for trunk?

Best regards

Thomas

gcc/fortran/ChangeLog:

* check.cc (gfc_check_mask): Handle BT_INSIGNED.
* gfortran.h (enum gfc_isym_id): Add GFC_ISYM_UMASKL and
GFC_ISYM_UMASKR.
* gfortran.texi: List UMASKL and UMASKR, remove unsigned future
unsigned arguments for MASKL and MASKR.
* intrinsic.cc (add_functions): Add UMASKL and UMASKR.
* intrinsic.h (gfc_simplify_umaskl): New function.
(gfc_simplify_umaskr): New function.
(gfc_resolve_umasklr): New function.
* intrinsic.texi: Document UMASKL and UMASKR.
* iresolve.cc (gfc_resolve_umasklr): New function.
* simplify.cc (gfc_simplify_umaskr): New function.
(gfc_simplify_umaskl): New function.

gcc/testsuite/ChangeLog:

* gfortran.dg/unsigned_39.f90: New test.diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 304ca1b9ae8..2d4af8e7df3 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -4466,7 +4466,12 @@ gfc_check_mask (gfc_expr *i, gfc_expr *kind)
 {
   int k;
 
-  if (!type_check (i, 0, BT_INTEGER))
+  if (flag_unsigned)
+{
+  if (!type_check2 (i, 0, BT_INTEGER, BT_UNSIGNED))
+	return false;
+}
+  else if (!type_check (i, 0, BT_INTEGER))
 return false;
 
   if (!nonnegative_check ("I", i))
@@ -4478,7 +4483,7 @@ gfc_check_mask (gfc_expr *i, gfc_expr *kind)
   if (kind)
 gfc_extract_int (kind, &k);
   else
-k = gfc_default_integer_kind;
+k = i->ts.type == BT_UNSIGNED ? gfc_default_unsigned_kind : gfc_default_integer_kind;
 
   if (!less_than_bitsizekind ("I", i, k))
 return false;
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index dd599bc97a2..309095d74d5 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -699,6 +699,8 @@ enum gfc_isym_id
   GFC_ISYM_UBOUND,
   GFC_ISYM_UCOBOUND,
   GFC_ISYM_UMASK,
+  GFC_ISYM_UMASKL,
+  GFC_ISYM_UMASKR,
   GFC_ISYM_UNLINK,
   GFC_ISYM_UNPACK,
   GFC_ISYM_VERIFY,
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 3b2691649b0..429d8461f8f 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -2825,16 +2825,11 @@ The following intrinsics take unsigned arguments:
 The following intinsics are enabled with @option{-funsigned}:
 @itemize @bullet
 @item @code{UINT}, @pxref{UINT}
+@item @code{UMASKL}, @pxref{UMASKL}
+@item @code{UMASKR}, @pxref{UMASKR}
 @item @code{SELECTED_UNSIGNED_KIND}, @pxref{SELECTED_UNSIGNED_KIND}
 @end itemize
 
-The following intrinsics will take unsigned arguments
-in the future:
-@itemize @bullet
-@item @code{MASKL}, @pxref{MASKL}
-@item @code{MASKR}, @pxref{MASKR}
-@end itemize
-
 The following intrinsics are not yet implemented in GNU Fortran,
 but will take unsigned arguments once they have been:
 @itemize @bullet
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index 83b65d34e43..3fb1c63bbd4 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -2568,6 +2568,22 @@ add_functions (void)
 
   make_generic ("maskr", GFC_ISYM_MASKR, GFC_STD_F2008);
 
+  add_sym_2 ("umaskl", GFC_ISYM_UMASKL, CLASS_ELEMENTAL, ACTUAL_NO,
+	 BT_INTEGER, di, GFC_STD_F2008,
+	 gfc_check_mask, gfc_simplify_umaskl, gfc_resolve_umasklr,
+	 i, BT_INTEGER, di, REQUIRED,
+	 kind, BT_INTEGER, di, OPTIONAL);
+
+  make_generic ("umaskl", GFC_ISYM_UMASKL, GFC_STD_F2008);
+
+  add_sym_2 ("umaskr", GFC_ISYM_UMASKR, CLASS_ELEMENTAL, ACTUAL_NO,
+	 BT_INTEGER, di, GFC_STD_F2008,
+	 gfc_check_mask, gfc_simplify_umaskr, gfc_resolve_umasklr,
+	 i, BT_INTEGER, di, REQUIRED,
+	 kind, BT_INTEGER, di, OPTIONAL);
+
+  make_generic ("umaskr", GFC_ISYM_UMASKR, GFC_STD_F2008);
+
   add_sym_2 ("matmul", GFC_ISYM_MATMUL, CLASS_TRANSFORMATIONAL, ACTUAL_NO, BT_REAL, dr, GFC_STD_F95,
 	 gfc_check_matmul, gfc_simplify_matmul, gfc_resolve_matmul,
 	 ma, BT_REAL, dr, REQUIRED, mb, BT_REAL, dr, REQUIRED);
diff --git a/gcc/fortran/intrinsic.h b/gcc/fortran/intrinsic.h
index ea29219819d..61d85eedc69 100644
--- a/gcc/fortran/intrinsic.h
+++ b/gcc/fortran/intrinsic.h
@@ -434,6 +434,8 @@ gfc_expr *gfc_simplify_transpose (gfc_expr *);
 gfc_expr *gfc_simplify_trim (gfc_expr *);
 gfc_expr *gfc_simplify_ubound (gfc_expr *, gfc_

CVS: cvs.openbsd.org: ports

2024-10-27 Thread Thomas Frohwein

CVSROOT:/cvs
Module name:ports
Changes by: t...@cvs.openbsd.org2024/10/27 08:13:05

Modified files:
games/naev : Makefile 
Removed files:
games/naev/patches: patch-src_utf8_c 

Log message:
remove unneeded patch including sys/malloc.h; ok sthen@

[patch, Fortran] Introduce unsigned versions of MASKL and MASKR


Hello world,

MASKR and MASKL are obvious candidates for unsigned, too; in the
previous version of the doc patch, I had promised that these would
take unsigned arguments in the future. What I had in mind was
they could take an unsigned argument and return an unsigned result.

Thinking about this a bit more, I realized that this was actually a
bad idea; nowhere else do we allow UNSIGNED for bit counting, and things
like checking for negative number of bits (which is illegal) would not
work.

Hence, two new intrinsics, UMASKL and UMASKR.  Regressoin-tesed
(and this time, I added the intrinsics to the list, so no trouble
expected there :-)

OK for trunk?

Best regards

Thomas

gcc/fortran/ChangeLog:

* check.cc (gfc_check_mask): Handle BT_INSIGNED.
* gfortran.h (enum gfc_isym_id): Add GFC_ISYM_UMASKL and
GFC_ISYM_UMASKR.
* gfortran.texi: List UMASKL and UMASKR, remove unsigned future
unsigned arguments for MASKL and MASKR.
* intrinsic.cc (add_functions): Add UMASKL and UMASKR.
* intrinsic.h (gfc_simplify_umaskl): New function.
(gfc_simplify_umaskr): New function.
(gfc_resolve_umasklr): New function.
* intrinsic.texi: Document UMASKL and UMASKR.
* iresolve.cc (gfc_resolve_umasklr): New function.
* simplify.cc (gfc_simplify_umaskr): New function.
(gfc_simplify_umaskl): New function.

gcc/testsuite/ChangeLog:

* gfortran.dg/unsigned_39.f90: New test.diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 304ca1b9ae8..2d4af8e7df3 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -4466,7 +4466,12 @@ gfc_check_mask (gfc_expr *i, gfc_expr *kind)
 {
   int k;
 
-  if (!type_check (i, 0, BT_INTEGER))
+  if (flag_unsigned)
+{
+  if (!type_check2 (i, 0, BT_INTEGER, BT_UNSIGNED))
+	return false;
+}
+  else if (!type_check (i, 0, BT_INTEGER))
 return false;
 
   if (!nonnegative_check ("I", i))
@@ -4478,7 +4483,7 @@ gfc_check_mask (gfc_expr *i, gfc_expr *kind)
   if (kind)
 gfc_extract_int (kind, &k);
   else
-k = gfc_default_integer_kind;
+k = i->ts.type == BT_UNSIGNED ? gfc_default_unsigned_kind : gfc_default_integer_kind;
 
   if (!less_than_bitsizekind ("I", i, k))
 return false;
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index dd599bc97a2..309095d74d5 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -699,6 +699,8 @@ enum gfc_isym_id
   GFC_ISYM_UBOUND,
   GFC_ISYM_UCOBOUND,
   GFC_ISYM_UMASK,
+  GFC_ISYM_UMASKL,
+  GFC_ISYM_UMASKR,
   GFC_ISYM_UNLINK,
   GFC_ISYM_UNPACK,
   GFC_ISYM_VERIFY,
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 3b2691649b0..429d8461f8f 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -2825,16 +2825,11 @@ The following intrinsics take unsigned arguments:
 The following intinsics are enabled with @option{-funsigned}:
 @itemize @bullet
 @item @code{UINT}, @pxref{UINT}
+@item @code{UMASKL}, @pxref{UMASKL}
+@item @code{UMASKR}, @pxref{UMASKR}
 @item @code{SELECTED_UNSIGNED_KIND}, @pxref{SELECTED_UNSIGNED_KIND}
 @end itemize
 
-The following intrinsics will take unsigned arguments
-in the future:
-@itemize @bullet
-@item @code{MASKL}, @pxref{MASKL}
-@item @code{MASKR}, @pxref{MASKR}
-@end itemize
-
 The following intrinsics are not yet implemented in GNU Fortran,
 but will take unsigned arguments once they have been:
 @itemize @bullet
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index 83b65d34e43..3fb1c63bbd4 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -2568,6 +2568,22 @@ add_functions (void)
 
   make_generic ("maskr", GFC_ISYM_MASKR, GFC_STD_F2008);
 
+  add_sym_2 ("umaskl", GFC_ISYM_UMASKL, CLASS_ELEMENTAL, ACTUAL_NO,
+	 BT_INTEGER, di, GFC_STD_F2008,
+	 gfc_check_mask, gfc_simplify_umaskl, gfc_resolve_umasklr,
+	 i, BT_INTEGER, di, REQUIRED,
+	 kind, BT_INTEGER, di, OPTIONAL);
+
+  make_generic ("umaskl", GFC_ISYM_UMASKL, GFC_STD_F2008);
+
+  add_sym_2 ("umaskr", GFC_ISYM_UMASKR, CLASS_ELEMENTAL, ACTUAL_NO,
+	 BT_INTEGER, di, GFC_STD_F2008,
+	 gfc_check_mask, gfc_simplify_umaskr, gfc_resolve_umasklr,
+	 i, BT_INTEGER, di, REQUIRED,
+	 kind, BT_INTEGER, di, OPTIONAL);
+
+  make_generic ("umaskr", GFC_ISYM_UMASKR, GFC_STD_F2008);
+
   add_sym_2 ("matmul", GFC_ISYM_MATMUL, CLASS_TRANSFORMATIONAL, ACTUAL_NO, BT_REAL, dr, GFC_STD_F95,
 	 gfc_check_matmul, gfc_simplify_matmul, gfc_resolve_matmul,
 	 ma, BT_REAL, dr, REQUIRED, mb, BT_REAL, dr, REQUIRED);
diff --git a/gcc/fortran/intrinsic.h b/gcc/fortran/intrinsic.h
index ea29219819d..61d85eedc69 100644
--- a/gcc/fortran/intrinsic.h
+++ b/gcc/fortran/intrinsic.h
@@ -434,6 +434,8 @@ gfc_expr *gfc_simplify_transpose (gfc_expr *);
 gfc_expr *gfc_simplify_trim (gfc_expr *);
 gfc_expr *gfc_simplify_ubound (gfc_expr *, gfc_

Re: [PATCH v2 00/10] net/mlx5: improve MAC address and VLAN add latency

2024-10-27 Thread Thomas Monjalon

24/10/2024 16:11, Raslan Darawsheh:
> Series applied to next-net-mlx,

This series fails to build on MinGW because of the weak stubs.
Please check why.
Note: I'm off for a week.

[Patch, fortran] [13-15 regressions] PR115070 & 115348

2024-10-27 Thread Paul Richard Thomas

Pushed as 'obvious' in commit r15-4702. This patch has been on my tree
since July so I thought to get it out of the way before it died of bit-rot.
Will backport in a week.

Fortran: Fix regressions with intent(out) class[PR115070, PR115348].

2024-10-27  Paul Thomas  

gcc/fortran
PR fortran/115070
PR fortran/115348
* trans-expr.cc (gfc_trans_class_init_assign): If all the
components of the default initializer are null for a scalar,
build an empty statement to prevent prior declarations from
disappearing.

gcc/testsuite/
PR fortran/115070
* gfortran.dg/pr115070.f90: New test.

PR fortran/115348
* gfortran.dg/pr115348.f90: New test.

Paul

[Patch, fortran] [13-15 regressions] PR115070 & 115348

2024-10-27 Thread Paul Richard Thomas

Pushed as 'obvious' in commit r15-4702. This patch has been on my tree
since July so I thought to get it out of the way before it died of bit-rot.
Will backport in a week.

Fortran: Fix regressions with intent(out) class[PR115070, PR115348].

2024-10-27  Paul Thomas  

gcc/fortran
PR fortran/115070
PR fortran/115348
* trans-expr.cc (gfc_trans_class_init_assign): If all the
components of the default initializer are null for a scalar,
build an empty statement to prevent prior declarations from
disappearing.

gcc/testsuite/
PR fortran/115070
* gfortran.dg/pr115070.f90: New test.

PR fortran/115348
* gfortran.dg/pr115348.f90: New test.

Paul

[gcc r15-4702] Fortran: Fix regressions with intent(out) class[PR115070, PR115348].

2024-10-27 Thread Paul Thomas via Gcc-cvs

https://gcc.gnu.org/g:ed8ca972f8857869d2bb4a416994bb896eb1c34e

commit r15-4702-ged8ca972f8857869d2bb4a416994bb896eb1c34e
Author: Paul Thomas 
Date:   Sun Oct 27 12:40:42 2024 +

Fortran: Fix regressions with intent(out) class[PR115070, PR115348].

2024-10-27  Paul Thomas  

gcc/fortran
PR fortran/115070
PR fortran/115348
* trans-expr.cc (gfc_trans_class_init_assign): If all the
components of the default initializer are null for a scalar,
build an empty statement to prevent prior declarations from
disappearing.

gcc/testsuite/
PR fortran/115070
* gfortran.dg/pr115070.f90: New test.

PR fortran/115348
* gfortran.dg/pr115348.f90: New test.

Diff:
---
 gcc/fortran/trans-expr.cc  | 29 
 gcc/testsuite/gfortran.dg/pr115070.f90 | 28 +++
 gcc/testsuite/gfortran.dg/pr115348.f90 | 35 ++
 3 files changed, 80 insertions(+), 12 deletions(-)

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 663d762df88d..ff8cde93ef4f 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -1791,10 +1791,12 @@ gfc_trans_class_init_assign (gfc_code *code)
 {
   stmtblock_t block;
   tree tmp;
+  bool cmp_flag = true;
   gfc_se dst,src,memsz;
   gfc_expr *lhs, *rhs, *sz;
   gfc_component *cmp;
   gfc_symbol *sym;
+  gfc_ref *ref;
 
   gfc_start_block (&block);
 
@@ -1812,24 +1814,25 @@ gfc_trans_class_init_assign (gfc_code *code)
   rhs->rank = 0;
 
   /* Check def_init for initializers.  If this is an INTENT(OUT) dummy with all
- default initializer components NULL, return NULL_TREE and use the passed
- value as required by F2018(8.5.10).  */
+ default initializer components NULL, use the passed value even though
+ F2018(8.5.10) asserts that it should considered to be undefined. This is
+ needed for consistency with other brands.  */
   sym = code->expr1->expr_type == EXPR_VARIABLE ? code->expr1->symtree->n.sym
: NULL;
   if (code->op != EXEC_ALLOCATE
   && sym && sym->attr.dummy
   && sym->attr.intent == INTENT_OUT)
 {
-  if (!lhs->ref && lhs->symtree->n.sym->attr.dummy)
+  ref = rhs->ref;
+  while (ref && ref->next)
+   ref = ref->next;
+  cmp = ref->u.c.component->ts.u.derived->components;
+  for (; cmp; cmp = cmp->next)
{
- cmp = rhs->ref->next->u.c.component->ts.u.derived->components;
- for (; cmp; cmp = cmp->next)
-   {
- if (cmp->initializer)
-   break;
- else if (!cmp->next)
-   return NULL_TREE;
-   }
+ if (cmp->initializer)
+   break;
+ else if (!cmp->next)
+   cmp_flag = false;
}
 }
 
@@ -1843,7 +1846,7 @@ gfc_trans_class_init_assign (gfc_code *code)
   gfc_add_full_array_ref (lhs, tmparr);
   tmp = gfc_trans_class_array_init_assign (rhs, lhs, code->expr1);
 }
-  else
+  else if (cmp_flag)
 {
   /* Scalar initialization needs the _data component.  */
   gfc_add_data_component (lhs);
@@ -1873,6 +1876,8 @@ gfc_trans_class_init_assign (gfc_code *code)
tmp, build_empty_stmt (input_location));
}
 }
+  else
+tmp = build_empty_stmt (input_location);
 
   if (code->expr1->symtree->n.sym->attr.dummy
   && (code->expr1->symtree->n.sym->attr.optional
diff --git a/gcc/testsuite/gfortran.dg/pr115070.f90 
b/gcc/testsuite/gfortran.dg/pr115070.f90
new file mode 100644
index ..9378f770e2c6
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr115070.f90
@@ -0,0 +1,28 @@
+! { dg-do compile }
+!
+! Test the fix for PR115070
+!
+! Contributed by Sebastien Bardeau  
+!
+module my_mod
+  type my_type
+integer :: a
+  contains
+final :: myfinal
+  end type my_type
+contains
+  subroutine my_sub(obs)
+use ieee_arithmetic
+class(my_type), intent(out) :: obs
+  end subroutine my_sub
+  subroutine myfinal (arg)
+type (my_type) :: arg
+print *, arg%a
+  end
+end module my_mod
+
+  use my_mod
+  type (my_type) :: z
+  z%a = 42
+  call my_sub (z)
+end
diff --git a/gcc/testsuite/gfortran.dg/pr115348.f90 
b/gcc/testsuite/gfortran.dg/pr115348.f90
new file mode 100644
index ..bc644b2f1c0c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr115348.f90
@@ -0,0 +1,35 @@
+! { dg-do compile }
+! { dg-options "-fcheck=recursion" }
+!
+! Test the fix for pr115348.
+!
+! Contributed by Maxime van den Bossche  
+!
+module mymodule
+implicit none
+
+type mytype
+integer :: mynumber
+contains
+procedure :: myroutine
+end type m

Bug#1062979: tango-db: the upgraded version of tango-db is not compatible with maria-db from bookworm

2024-10-27 Thread Thomas Braun

> Santiago Ruano Rincón  hat am 25.10.2024 20:15 CEST 
> geschrieben:
> Sorry for the noise. I can confirm there is an issue in bookworm, and it
> is present even without upgrading from bullseye. Which makes sense with
> https://gitlab.com/tango-controls/TangoDatabase/-/issues/69
> 
> I will propose a bookworm update soon.

Yes, this is indeed an issue on bookworm as well. But the problem only occurs 
if you use the table and not when you create them.

Based on Santiago's MR 
https://gitlab.com/tango-controls/TangoDatabase/-/merge_requests/82 I've 
created a new one with a test and an upgrade script, see 
https://gitlab.com/tango-controls/TangoDatabase/-/merge_requests/95.

Please test.

Thomas

-- 
debian-science-maintainers mailing list
debian-science-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1062979: tango-db: the upgraded version of tango-db is not compatible with maria-db from bookworm

2024-10-27 Thread Thomas Braun

> Santiago Ruano Rincón  hat am 25.10.2024 20:15 CEST 
> geschrieben:
> Sorry for the noise. I can confirm there is an issue in bookworm, and it
> is present even without upgrading from bullseye. Which makes sense with
> https://gitlab.com/tango-controls/TangoDatabase/-/issues/69
> 
> I will propose a bookworm update soon.

Yes, this is indeed an issue on bookworm as well. But the problem only occurs 
if you use the table and not when you create them.

Based on Santiago's MR 
https://gitlab.com/tango-controls/TangoDatabase/-/merge_requests/82 I've 
created a new one with a test and an upgrade script, see 
https://gitlab.com/tango-controls/TangoDatabase/-/merge_requests/95.

Please test.

Thomas

Re: [PATCH 08/36] next-cube: introduce next-scsi device

Am Wed, 23 Oct 2024 09:58:24 +0100
schrieb Mark Cave-Ayland :

> This device is intended to hold the ESP SCSI controller and the NeXT SCSI 
> CSRs.
> Start by creating the device and moving the ESP SCSI controller to be an
> embedded child device.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/m68k/next-cube.c | 93 -
>  1 file changed, 74 insertions(+), 19 deletions(-)

Reviewed-by: Thomas Huth

Re: [PATCH 03/36] next-cube: remove overlap between next.dma and next.mmio memory regions

Am Sat, 26 Oct 2024 22:13:25 +0100
schrieb Mark Cave-Ayland :

> On 26/10/2024 08:56, Thomas Huth wrote:
> 
> > Am Wed, 23 Oct 2024 09:58:19 +0100
> > schrieb Mark Cave-Ayland :
> >   
> >> Change the start of the next.mmio memory region so that it follows on 
> >> directly
> >> after the next.dma memory region, adjusting the address offsets in
> >> next_mmio_read() and next_mmio_write() accordingly.
> >>
> >> Signed-off-by: Mark Cave-Ayland 
> >> ---
> >>   hw/m68k/next-cube.c | 28 ++--
> >>   1 file changed, 14 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/hw/m68k/next-cube.c b/hw/m68k/next-cube.c
> >> index 4e8e55a8bd..e1d94c1ce0 100644
> >> --- a/hw/m68k/next-cube.c
> >> +++ b/hw/m68k/next-cube.c
> >> @@ -266,23 +266,23 @@ static uint64_t next_mmio_read(void *opaque, hwaddr 
> >> addr, unsigned size)
> >>   uint64_t val;
> >>   
> >>   switch (addr) {
> >> -case 0x7000:
> >> +case 0x2000:
> >>   /* DPRINTF("Read INT status: %x\n", s->int_status); */
> >>   val = s->int_status;
> >>   break;
> >>   
> >> -case 0x7800:
> >> +case 0x2800:
> >>   DPRINTF("MMIO Read INT mask: %x\n", s->int_mask);
> >>   val = s->int_mask;
> >>   break;
> >>   
> >> -case 0xc000 ... 0xc003:
> >> -val = extract32(s->scr1, (4 - (addr - 0xc000) - size) << 3,
> >> +case 0x7000 ... 0x7003:
> >> +val = extract32(s->scr1, (4 - (addr - 0x7000) - size) << 3,
> >>   size << 3);
> >>   break;
> >>   
> >> -case 0xd000 ... 0xd003:
> >> -val = extract32(s->scr2, (4 - (addr - 0xd000) - size) << 3,
> >> +case 0x8000 ... 0x8003:
> >> +val = extract32(s->scr2, (4 - (addr - 0x8000) - size) << 3,
> >>   size << 3);
> >>   break;
> >>   
> >> @@ -301,25 +301,25 @@ static void next_mmio_write(void *opaque, hwaddr 
> >> addr, uint64_t val,
> >>   NeXTPC *s = NEXT_PC(opaque);
> >>   
> >>   switch (addr) {
> >> -case 0x7000:
> >> +case 0x2000:
> >>   DPRINTF("INT Status old: %x new: %x\n", s->int_status,
> >>   (unsigned int)val);
> >>   s->int_status = val;
> >>   break;
> >>   
> >> -case 0x7800:
> >> +case 0x2800:
> >>   DPRINTF("INT Mask old: %x new: %x\n", s->int_mask, (unsigned 
> >> int)val);
> >>   s->int_mask  = val;
> >>   break;  
> > 
> > Could you please add comments at the end of the "case" lines, stating which
> > mmio addresses are handled in each case? Otherwise, it's harder to grep for
> > certain addresses later. E.g:
> > 
> >  case 0x2800: /* 0x2007800 */  
> 
> If you think it will help? Presumably this is to aid with comparing with 
> other source 
> code/documentation?

Yes, it will help with 1) debugging code that is running in the guest (so
you can find IO addresses that it is accessing more easily) and 2) help
when comparing the code with "Previous":

 https://sourceforge.net/p/previous/code/HEAD/tree/trunk/src/ioMemTabNEXT.c#l36

> >> @@ -1000,7 +1000,7 @@ static void next_cube_init(MachineState *machine)
> >>   sysbus_create_simple(TYPE_NEXTFB, 0x0B00, NULL);
> >>   
> >>   /* MMIO */
> >> -sysbus_mmio_map(SYS_BUS_DEVICE(pcdev), 0, 0x0200);
> >> +sysbus_mmio_map(SYS_BUS_DEVICE(pcdev), 0, 0x02005000);  
> > 
> > Why 0x02005000 and not directly 0x02007000 ?  
> 
> Before this patch the output of "info mtree" shows as follows:
> 
> (qemu) info mtree
> address-space: cpu-memory-0
> address-space: memory
>- (prio 0, i/o): system
>  -0001 (prio 0, rom): alias next.rom2 
> @next.rom 
> -0001
>  0100-0101 (prio 0, rom): next.rom
>  0200-02004fff (prio 0, i/o): next.dma
>  0200-020c (prio 0, i/o): next.mmio
>  0200e000-0200efff (prio 0, i/o): next.kbd
>  020c-020c003f (prio 0, ram): next.bmapmem

Re: [PATCH 07/36] next-cube: introduce next_pc_init() object init function

Am Wed, 23 Oct 2024 09:58:23 +0100
schrieb Mark Cave-Ayland :

> Move initialisation of the memory regions and GPIOs from next_pc_realize() to
> the new next_pc_init() function.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/m68k/next-cube.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/m68k/next-cube.c b/hw/m68k/next-cube.c
> index 0c3f8780a1..3b4c361156 100644
> --- a/hw/m68k/next-cube.c
> +++ b/hw/m68k/next-cube.c
> @@ -897,20 +897,24 @@ static void next_pc_reset(DeviceState *dev)
>  
>  static void next_pc_realize(DeviceState *dev, Error **errp)
>  {
> -NeXTPC *s = NEXT_PC(dev);
> -SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
> +/* SCSI */
> +next_scsi_init(dev);
> +}
> +
> +static void next_pc_init(Object *obj)
> +{
> +NeXTPC *s = NEXT_PC(obj);
> +SysBusDevice *sbd = SYS_BUS_DEVICE(obj);
>  
> -qdev_init_gpio_in(dev, next_irq, NEXT_NUM_IRQS);
> +qdev_init_gpio_in(DEVICE(obj), next_irq, NEXT_NUM_IRQS);
>  
>  memory_region_init_io(&s->mmiomem, OBJECT(s), &next_mmio_ops, s,
>"next.mmio", 0x9000);
>  memory_region_init_io(&s->scrmem, OBJECT(s), &next_scr_ops, s,
>"next.scr", 0x2);
> +
>  sysbus_init_mmio(sbd, &s->mmiomem);
>  sysbus_init_mmio(sbd, &s->scrmem);
> -
> -/* SCSI */
> -next_scsi_init(dev);
>  }
>  
>  /*
> @@ -972,6 +976,7 @@ static void next_pc_class_init(ObjectClass *klass, void 
> *data)
>  static const TypeInfo next_pc_info = {
>  .name = TYPE_NEXT_PC,
>  .parent = TYPE_SYS_BUS_DEVICE,
> +.instance_init = next_pc_init,
>  .instance_size = sizeof(NeXTPC),
>  .class_init = next_pc_class_init,
>  };

Reviewed-by: Thomas Huth

Re: [PATCH 06/36] next-cube: move next_scsi_init() to next_pc_realize()

Am Wed, 23 Oct 2024 09:58:22 +0100
schrieb Mark Cave-Ayland :

> This reflects that the SCSI interface exists within the NeXT Peripheral
> Controller (PC).
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/m68k/next-cube.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Thomas Huth

[kmymoney] [Bug 488491] Make 5.2 release

2024-10-27 Thread Thomas Baumgart

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

Thomas Baumgart  changed:

   What|Removed |Added

 Depends on||495417


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=495417
[Bug 495417] Currency conversion in category/accounts view is not correct
-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney] [Bug 495417] Currency conversion in category/accounts view is not correct

2024-10-27 Thread Thomas Baumgart via KMyMoney-devel

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

Thomas Baumgart  changed:

   What|Removed |Added

 Blocks||488491


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=488491
[Bug 488491] Make 5.2 release
-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 488491] Make 5.2 release

2024-10-27 Thread Thomas Baumgart via KMyMoney-devel

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

Thomas Baumgart  changed:

   What|Removed |Added

 Depends on||495417


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=495417
[Bug 495417] Currency conversion in category/accounts view is not correct
-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney] [Bug 495417] Currency conversion in category/accounts view is not correct

2024-10-27 Thread Thomas Baumgart

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

Thomas Baumgart  changed:

   What|Removed |Added

 Blocks||488491


Referenced Bugs:

https://bugs.kde.org/show_bug.cgi?id=488491
[Bug 488491] Make 5.2 release
-- 
You are receiving this mail because:
You are watching all bug changes.

[kmymoney] [Bug 495417] New: Currency conversion in category/accounts view is not correct

2024-10-27 Thread Thomas Baumgart

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

Bug ID: 495417
   Summary: Currency conversion in category/accounts view is not
correct
Classification: Applications
   Product: kmymoney
   Version: git (master)
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kmymoney-de...@kde.org
  Reporter: tbaumg...@kde.org
  Target Milestone: ---

Created attachment 175267
  --> https://bugs.kde.org/attachment.cgi?id=175267&action=edit
Testfile showing the problem

SUMMARY
Opening a test file shows incorrect value after currency conversion in
categories view

STEPS TO REPRODUCE
1. Open attached test file
2. Select categories view
3. 

OBSERVED RESULT
Sales-Tax (FRF) shows Balance of 1047,30 FF and Value of 159,70 EUR

EXPECTED RESULT
Sales-Tax (FRF) shows Balance of 1047,30 FF and Value of 159,66 EUR

ADDITIONAL INFORMATION
The values in the transactions and the currency conversion rate between EUR and
FF have correct values. Multiplying 1047,30 FF with the included conversion
rate in an external calculator yields 159,66 EUR.

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

[kmymoney] [Bug 495417] New: Currency conversion in category/accounts view is not correct

2024-10-27 Thread Thomas Baumgart via KMyMoney-devel

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

Bug ID: 495417
   Summary: Currency conversion in category/accounts view is not
correct
Classification: Applications
   Product: kmymoney
   Version: git (master)
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kmymoney-devel@kde.org
  Reporter: tbaumg...@kde.org
  Target Milestone: ---

Created attachment 175267
  --> https://bugs.kde.org/attachment.cgi?id=175267&action=edit
Testfile showing the problem

SUMMARY
Opening a test file shows incorrect value after currency conversion in
categories view

STEPS TO REPRODUCE
1. Open attached test file
2. Select categories view
3. 

OBSERVED RESULT
Sales-Tax (FRF) shows Balance of 1047,30 FF and Value of 159,70 EUR

EXPECTED RESULT
Sales-Tax (FRF) shows Balance of 1047,30 FF and Value of 159,66 EUR

ADDITIONAL INFORMATION
The values in the transactions and the currency conversion rate between EUR and
FF have correct values. Multiplying 1047,30 FF with the included conversion
rate in an external calculator yields 159,66 EUR.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [pushed] doc, fortran: Add a missing menu item.


Am 27.10.24 um 00:15 schrieb Iain Sandoe:

Tested on x86_64-darwin21 and linux, with makeinfo 6.7 pushed to trunk,
thanks


Thanks!

For the record, makeinfo 6.8 did not show this as an error.

Best regards

Thomas

Re: [pushed] doc, fortran: Add a missing menu item.


Am 27.10.24 um 00:15 schrieb Iain Sandoe:

Tested on x86_64-darwin21 and linux, with makeinfo 6.7 pushed to trunk,
thanks


Thanks!

For the record, makeinfo 6.8 did not show this as an error.

Best regards

Thomas

[Bug 2031969] Re: Kernel 6.x: Suspend & Power off

2024-10-27 Thread Thomas Pohl

A feeling of familiarity kicks in. Nice to meet you on Oracular.

Linux uENVY 6.11.0-9-generic #9-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 14
13:19:59 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

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

Title:
  Kernel 6.x: Suspend & Power off

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


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

[Kernel-packages] [Bug 2031969] Re: Kernel 6.x: Suspend & Power off

2024-10-27 Thread Thomas Pohl

A feeling of familiarity kicks in. Nice to meet you on Oracular.

Linux uENVY 6.11.0-9-generic #9-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 14
13:19:59 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2031969

Title:
  Kernel 6.x: Suspend & Power off

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Lunar:
  Won't Fix
Status in linux source package in Mantic:
  Won't Fix
Status in linux source package in Noble:
  Confirmed

Bug description:
  Since update to version 23.04 I am facing several problems related to
  system suspend and shutdownon a HP Envy 15 notebook (2016). The system
  refuses to wake up from standby mode, especially if it has run for a
  longer time. Screen is black, no response to keyboard or trackpad
  actions, power button led is on. The only way out of here is a long
  press on the power button.

  Another problem with this and I think it's kind of related. If you
  want to shut down the computer after a long runtime, the machine won't
  power off.  In the logs you can see the steps for shutting down the
  OS, but sometimes the machine stays powered on. The power led is on,
  screen is black, no response to keyboard or trackpad actions. System
  has to be powered off by a long press on the power button.

  Ubuntu 6.2.0-27.28-generic 6.2.15

  ProblemType: Bug
  DistroRelease: Ubuntu 23.04
  Package: linux-image-6.2.0-27-generic 6.2.0-27.28
  ProcVersionSignature: Ubuntu 6.2.0-27.28-generic 6.2.15
  Uname: Linux 6.2.0-27-generic x86_64
  ApportVersion: 2.26.1-0ubuntu2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  tom2051 F wireplumber
   /dev/snd/seq:tom2037 F pipewire
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Aug 19 16:01:07 2023
  InstallationDate: Installed on 2018-07-01 (1875 days ago)
  InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
   Bus 001 Device 002: ID 04f2:b56d Chicony Electronics Co., Ltd HP Wide Vision 
HD
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: HP HP ENVY Notebook
  ProcEnviron:
   LANG=de_DE.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.2.0-27-generic 
root=UUID=1e8886f5-f232-49b1-af56-f83caee82bba ro quiet splash vt.handoff=7
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions:
   linux-restricted-modules-6.2.0-27-generic N/A
   linux-backports-modules-6.2.0-27-generic  N/A
   linux-firmware20230323.gitbcdcfbcf-0ubuntu1.5
  SourcePackage: linux
  UpgradeStatus: Upgraded to lunar on 2023-05-01 (109 days ago)
  dmi.bios.date: 11/10/2020
  dmi.bios.release: 15.62
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.62
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 81D2
  dmi.board.vendor: HP
  dmi.board.version: KBC Version 87.21
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.chassis.version: Chassis Version
  dmi.ec.firmware.release: 87.21
  dmi.modalias: 
dmi:bvnInsyde:bvrF.62:bd11/10/2020:br15.62:efr87.21:svnHP:pnHPENVYNotebook:pvrType1ProductConfigId:rvnHP:rn81D2:rvrKBCVersion87.21:cvnHP:ct10:cvrChassisVersion:skuZ6J78EA#ABD:
  dmi.product.family: 103C_5335KV
  dmi.product.name: HP ENVY Notebook
  dmi.product.sku: Z6J78EA#ABD
  dmi.product.version: Type1ProductConfigId
  dmi.sys.vendor: HP

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Re: Leo's jupytext code works!


On Thursday, October 24, 2024 at 7:14:08 PM UTC-4 Thomas Passin wrote:

A very small addition to VR3's code will allow the notebook to be rendered, 
and even executed.


Here's an example of VR3 rendering a converted jupyter notebook (I did by 
hand what that "small addition to VR3's code" would do).
 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/bc5ed934-9847-44bb-9373-e5c317463febn%40googlegroups.com.

Re: [patch, Fortran, doc] Update descriptions for UNSIGNED


Am 26.10.24 um 22:10 schrieb Iain Sandoe:

Pushed (4727bfb37701f3fef98a5f8b60dcd2daa82e8143).

This seems to have broken —enable-languages=all bootstrap with

  /src-local/gcc-master/gcc/fortran/intrinsic.texi:39: node `Intrinsic 
Procedures' lacks menu item for `UINT' despite being its Up target
/src-local/gcc-master/gcc/fortran/intrinsic.texi:14934: warning: node prev 
`UMASK' in menu `UCOBOUND' and in sectioning `UINT’ differ


That is weird - if this is not picked up with "make info", "make html"
and "make pdf", what command is needed to trigger it?  Or is it
--enable-languages=all vs. --enable-languages=c,c++,fortran which I use?


I think the following patch (which will no doubt be whitespace-mangled my 
mailer) is needed - under test


If you're already testing it, please commit if it passes (approved if
any approval is needed).

Thanks for the help!

Best regards

Thomas




diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 0354704e4d0..f47fa3bbd5e 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -321,6 +321,7 @@ Some basic guidelines for editing this document:
  * @code{TTYNAM}:TTYNAM,Get the name of a terminal device
  * @code{UBOUND}:UBOUND,Upper dimension bounds of an array
  * @code{UCOBOUND}:  UCOBOUND,  Upper codimension bounds of an array
+* @code{UINT}:  UINT,  Convert to an unsigned integer type
  * @code{UMASK}: UMASK, Set the file creation mask
  * @code{UNLINK}:UNLINK,Remove a file from the file system
  * @code{UNPACK}:UNPACK,Unpack an array of rank one into an array

Re: [patch, Fortran, doc] Update descriptions for UNSIGNED


Am 26.10.24 um 22:10 schrieb Iain Sandoe:

Pushed (4727bfb37701f3fef98a5f8b60dcd2daa82e8143).

This seems to have broken —enable-languages=all bootstrap with

  /src-local/gcc-master/gcc/fortran/intrinsic.texi:39: node `Intrinsic 
Procedures' lacks menu item for `UINT' despite being its Up target
/src-local/gcc-master/gcc/fortran/intrinsic.texi:14934: warning: node prev 
`UMASK' in menu `UCOBOUND' and in sectioning `UINT’ differ


That is weird - if this is not picked up with "make info", "make html"
and "make pdf", what command is needed to trigger it?  Or is it
--enable-languages=all vs. --enable-languages=c,c++,fortran which I use?


I think the following patch (which will no doubt be whitespace-mangled my 
mailer) is needed - under test


If you're already testing it, please commit if it passes (approved if
any approval is needed).

Thanks for the help!

Best regards

Thomas




diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 0354704e4d0..f47fa3bbd5e 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -321,6 +321,7 @@ Some basic guidelines for editing this document:
  * @code{TTYNAM}:TTYNAM,Get the name of a terminal device
  * @code{UBOUND}:UBOUND,Upper dimension bounds of an array
  * @code{UCOBOUND}:  UCOBOUND,  Upper codimension bounds of an array
+* @code{UINT}:  UINT,  Convert to an unsigned integer type
  * @code{UMASK}: UMASK, Set the file creation mask
  * @code{UNLINK}:UNLINK,Remove a file from the file system
  * @code{UNPACK}:UNPACK,Unpack an array of rank one into an array

Bug#1086085: dracut/experimental FTBFS: Could not find a Linux kernel version to test with!



In dracut 103 (which built correctly on our buildd)
the code for checking the kernel name was located in run-qemu. It was
then moved to test-functions in the upstream commit a94ba79e49bcfec92c

--
regards Thomas

Bug#1086085: dracut/experimental FTBFS: Could not find a Linux kernel version to test with!



In dracut 103 (which built correctly on our buildd)
the code for checking the kernel name was located in run-qemu. It was
then moved to test-functions in the upstream commit a94ba79e49bcfec92c

--
regards Thomas

Bug#1086085: dracut/experimental FTBFS: Could not find a Linux kernel version to test with!



Every test/TEST-*-* sources in its test.sh the file
test/test-functions which checks in line 74-89 the name of the kernel
file. It seem this does not work on the buildd. Maybe there's no
kernel installed in the buildd environment.

Can we force using qemu in a buildd environment?
Should we add a build dependency on a linux package?
his seems strange to me.

Or should we disable calling the clean target in the test
subdirectory in debian/rules?

-- 
regards Thomas

Bug#1086085: dracut/experimental FTBFS: Could not find a Linux kernel version to test with!



Every test/TEST-*-* sources in its test.sh the file
test/test-functions which checks in line 74-89 the name of the kernel
file. It seem this does not work on the buildd. Maybe there's no
kernel installed in the buildd environment.

Can we force using qemu in a buildd environment?
Should we add a build dependency on a linux package?
his seems strange to me.

Or should we disable calling the clean target in the test
subdirectory in debian/rules?

-- 
regards Thomas

Network security contact at Internet2?

2024-10-26 Thread Rob Thomas via NANOG

Dear team,

Does anyone have a network security contact at Internet2?  If so, I’d 
appreciate an introduction, please!

Thank you!
Rabbi Rob.
—
Rabbi Rob Thomas  Team Cymru
 "It is easy to believe in freedom of speech for those with whom we
  agree.”  - Leo McKern



signature.asc
Description: Message signed with OpenPGP

Fw: [mpg123-devel] 1.26 and 13.1 backports (Re: Security update mpg123 1.32.8: Frankenstein's Monster)

2024-10-26 Thread Thomas Orgis

Hi,

I looked especially at the versions in Debian and ported the buffer
overflow fix to 1.26 and 1.31.

Weitergeleitete Nachricht:

Datum: Sat, 26 Oct 2024 18:42:05 +0200
Von: Thomas Orgis 
An: mpg123-de...@lists.sourceforge.net, mpg123-us...@lists.sourceforge.net
Betreff: [mpg123-devel] 1.26 and 13.1 backports (Re: Security update mpg123 
1.32.8: Frankenstein's Monster)


Am Sat, 26 Oct 2024 17:38:40 +0200
schrieb Thomas Orgis : 

> I hereby announce mpg123 version 1.32.8. Get it at the usual places.
> Now.  

Observing that versions 1.26.x and 1.31.x are still in the wild
(meaning: Debian stable), I ported the recent security fix to those
release series. Please see recent commits to

svn://scm.orgis.org/mpg123/branches/1.26-fixes and
svn://scm.orgis.org/mpg123/branches/1.31-fixes

Current code is also visible under

https://scm.orgis.org/mpg123/branches/1.26-fixes/ and
https://scm.orgis.org/mpg123/branches/1.31-fixes/


Alrighty then,

Thomas


___
mpg123-devel mailing list
mpg123-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mpg123-devel

Re: [Talk-hu] Ehető gyümölcsök

2024-10-26 Thread Thomas Nagy

A lényeges tudnivaló, hogy a legfontosabb ismérv a taxon (avagy
species). Amennyiben nem sikerült minden kétséget kizáróan
beazonosítani a felmérő biológus által, elképzelhető, hogy
pontatlanabbul csak a genus vagy taxon:genus lett megadva, esetleg
description és egyéb további kulcsokkal. A taxon:hu illetve taxon:en
sosem volt "komolyan gondolva" - csak erre nem érdemes hagyatkozni.
Már felmerült egy újraírás és a jelek ezen irányú egységesítése. A
téma részletezése valóban lehetséges további csatornákon:
xmpp:osm-jelo...@conference.movim.eu
https://matrix.to/#/#osm-jeloles:matrix.org

On Sat, Oct 26, 2024 at 4:50 PM Szem  wrote:
>
> Szia!
> Hálás köszönet! (és a szerzőnek is!)
> Szem
>
> 2024.10.26. 16:32 keltezéssel, Tamás Vásony írta:
>
> Szia!
>
> Ezer éve volt erről meetup, itt vannak a gyümölcsöző sablonok, hátha ez segít:
> https://bkil.github.io/osm-taxon/#/
>
> Mátrixon valamelyik osm* szobábjában eléred a szerzőt.
>
> Tamás
>
>
> On Fri, 25 Oct 2024 at 15:04, Szem  wrote:
>>
>> Sziasztok!
>>
>> Fel szeretném tüntetni a bringás térképen (www.openbikemap.szerako.hu) a 
>> szabadban álldogáló és ehető gyümölcsöket termő növényeket (pl. /vad/alma, 
>> meggy, szeder stb. stb.), hogy aki arra jár a legalább tudjon róla. A 
>> felettébb hiányos bioszos tudásommal csak ehhez hasonló szűrést tudnék 
>> létrehozni:
>> species:hu~'.*körte.*|.*alma.*| ... '
>> ám nem minden esetben szerepel ez az érték.
>> Abban szeretném a hozzáértő segítségét kérni, hogyan tudnék teljesebb körű 
>> (pl. species, taxon stb.) meghatározásokat megadni az összes Magyarországon 
>> vadon előforduló és ehető gyümölcsöket termő növényekre.
>> Köszi!
>>
>> --
>>
>> Szem
>>
>> --
>> Talk-hu levelezőlista
>> Talk-hu@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-hu
>> Leiratkozás a fenti címen vagy  címre egy 
>> levél, témája "unsubscribe", tartalma mindegy.
>
>
>
> --
> Talk-hu levelezőlista
> Talk-hu@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hu
> Leiratkozás a fenti címen vagy  címre egy 
> levél, témája "unsubscribe", tartalma mindegy.

-- 
Talk-hu levelezőlista
Talk-hu@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hu
Leiratkozás a fenti címen vagy  címre egy 
levél, témája "unsubscribe", tartalma mindegy.

[kommit] [Bug 495351] kommitdiff

2024-10-26 Thread Thomas Braun

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

--- Comment #5 from Thomas Braun  ---
Okay, will wait patiently for the upstream fixes then.

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

[kommit] [Bug 495351] kommitdiff

2024-10-26 Thread Thomas Braun

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

--- Comment #3 from Thomas Braun  ---
Ah, kommit is qt5 based?
I'm running qt 6.8 on my system.

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

Bug#1086085: dracut/experimental FTBFS: Could not find a Linux kernel version to test with!

I think this is not a FTBFS, because only the autopkgtests are
failing and only for arm64.

-- 
regards Thomas

Bug#1086085: dracut/experimental FTBFS: Could not find a Linux kernel version to test with!

I think this is not a FTBFS, because only the autopkgtests are
failing and only for arm64.

-- 
regards Thomas

Re: [patch, Fortran, doc] Update descriptions for UNSIGNED


Hi Steve,


OK for trunk?



OK, but see below.


Pushed (4727bfb37701f3fef98a5f8b60dcd2daa82e8143). Thanks for
the proof-reading!

Best regards

Thomas

Re: [patch, Fortran, doc] Update descriptions for UNSIGNED


Hi Steve,


OK for trunk?



OK, but see below.


Pushed (4727bfb37701f3fef98a5f8b60dcd2daa82e8143). Thanks for
the proof-reading!

Best regards

Thomas

[gcc r15-4697] Add UNSIGNED for intrinsics.

2024-10-26 Thread Thomas Kﾃｶnig via Gcc-cvs

https://gcc.gnu.org/g:4727bfb37701f3fef98a5f8b60dcd2daa82e8143

commit r15-4697-g4727bfb37701f3fef98a5f8b60dcd2daa82e8143
Author: Thomas Koenig 
Date:   Sat Oct 26 19:20:14 2024 +0200

Add UNSIGNED for intrinsics.

gcc/fortran/ChangeLog:

* gfortran.texi: Correct reference to make clear that UNSIGNED
will not be part of F202Y.
Other clarifications.
Extend table of intrinsics, add links.
* intrinsic.texi: Add descriptions for UNSIGNED arguments.
* invoke.texi: Add anchor for -funsigned.

Diff:
---
 gcc/fortran/gfortran.texi  | 115 +++
 gcc/fortran/intrinsic.texi | 486 ++---
 gcc/fortran/invoke.texi|   1 +
 3 files changed, 409 insertions(+), 193 deletions(-)

diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 76326e625f8d..3b2691649b0e 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1192,7 +1192,7 @@ extensions.
 @menu
 * Extensions implemented in GNU Fortran::
 * Extensions not implemented in GNU Fortran::
-* Experimental features for Fortran 202Y::
+* Experimental features for future Fortran versions::
 @end menu
 
 
@@ -2702,19 +2702,19 @@ descriptor occurred, use @code{INQUIRE} to get the file 
position,
 count the characters up to the next @code{NEW_LINE} and then start
 reading from the position marked previously.
 
-@node Experimental features for Fortran 202Y
-@section Experimental features for Fortran 202Y
-@cindex Fortran 202Y
+@node Experimental features for future Fortran versions
+@section Experimental features future Fortran versions
+@cindex Future Fortran versions
 
 GNU Fortran supports some experimental features which have been
 proposed and accepted by the J3 standards committee.  These
 exist to give users a chance to try them out, and to provide
 a reference implementation.
 
-As these features have not been finalized, there is a chance that the
-version in the upcoming standard will differ from what GNU Fortran
-currently implements.  Stability of these implementations is therefore
-not guaranteed.
+As these features have not been included in the worklist for Fortran
+202Y by WG5, there is a chance that a version in any upcoming standard
+will differ from what GNU Fortran currently implements.  These
+features are therefore currently classified as an extension.
 
 @menu
 * Unsigned integers::
@@ -2723,11 +2723,12 @@ not guaranteed.
 @node Unsigned integers
 @subsection Unsigned integers
 @cindex Unsigned integers
-GNU Fortran supports unsigned integers according to
+If the @option{-funsigned} option is given, GNU Fortran supports
+unsigned integers according to
 @uref{https://j3-fortran.org/doc/year/24/24-116.txt, J3/24-116}.  The
-data type is called @code{UNSIGNED}.  For an unsigned type with $n$ bits,
-it implements integer arithmetic modulo @code{2**n}, comparable to the
-@code{unsigned} data type in C.
+data type is called @code{UNSIGNED}.  For an unsigned type with @code{n}
+bits, it implements integer arithmetic modulo @code{2**n}, comparable
+to the @code{unsigned} data type in C.
 
 The data type has @code{KIND} numbers comparable to other Fortran data
 types, which can be selected via the @code{SELECTED_UNSIGNED_KIND}
@@ -2771,31 +2772,75 @@ formatted and unformatted I/O.  For formatted I/O, the 
@code{B},
 values and values which would overflow are rejected with
 @code{-pedantic}.
 
-As of now, the following intrinsics take unsigned arguments:
+The following intrinsics take unsigned arguments:
 @itemize @bullet
-@item @code{BLT}, @code{BLE}, @code{BGE} and @code{BGT}. These intrinsics
-  are actually redundant because comparison operators could be used
-  directly.
-@item @code{IAND}, @code{IOR}, @code{IEOR} and @code{NOT}
-@item @code{BIT_SIZE}, @code{DIGITS} and @code{HUGE}
-@item @code{DSHIFTL} and @code{DSHIFTR}
-@item @code{IBCLR}, @code{IBITS} and @code{IBSET}
-@item @code{MIN} and @code{MAX}
-@item @code{ISHFT}, @code{ISHFTC}, @code{SHIFTL}, @code{SHIFTR} and
-  @code{SHIFTA}.
-@item @code{MERGE_BITS}
-@item @code{MOD} and @code{MODULO}
-@item @code{MVBITS}
-@item @code{RANGE}
-@item @code{TRANSFER}
-@item @code{SUM}, @code{PRODUCT}, @code{MATMUL} and @code{DOT_PRODUCT}
-@item @code{IANY}, @code{IALL} and @code{IPARITY}
-@item @code{RANDOM_NUMBER}
-@item @code{CSHIFT} and @code{EOSHIFT}
-@item @code{FINDLOC}
-@item @code{MAXVAL} and @code{MINVAL}
-@item @code{MAXLOC} and @code{MINLOC}.
+@item @code{BGE}, @pxref{BGE}
+@item @code{BGT}, @pxref{BGT}
+@item @code{BIT_SIZE}, @pxref{BIT_SIZE}
+@item @code{BLE}, @pxref{BLE}
+@item @code{BLT}, @pxref{BLT}
+@item @code{CSHIFT}, @pxref{CSHIFT}
+@item @code{DIGITS}, @pxref{DIGITS}
+@item @code{DOT_PRODUCT}, @pxref{DOT_PRODUCT}
+@item @code{DSHIFTL}, @pxref{DSHIFTL}
+@item @code{DSHIFTR}, @pxref{DSHIFTR}
+@item @code{EOSHIFT}, @pxref{EOSHIFT}
+@item @code{FINDLOC}, @pxref{FINDLOC}
+@item @code{HUGE}, @pxref{HUGE}
+@item @code{IALL

Re: [PATCH v7 5/9] net/zxdh: add msg chan enable implementation

2024-10-26 Thread Thomas Monjalon

22/10/2024 14:20, Junlong Wang:
> +enum MSG_VEC {
> +ZXDH_MSIX_FROM_PFVF = ZXDH_MSIX_INTR_MSG_VEC_BASE,
> +ZXDH_MSIX_FROM_MPF,
> +ZXDH_MSIX_FROM_RISCV,
> +ZXDH_MSG_VEC_NUM,
> +};
> +
>  enum BAR_MSG_RTN {
>  ZXDH_BAR_MSG_OK = 0,
>  ZXDH_BAR_MSG_ERR_MSGID,


Again these enums are uppercased and not prefixed.

Please check all other structs which are not prefixed.

Re: Tip - Finding Leo's Documentation More Easily

Right, I forgot about that.  I used to copy the UNLs that way until I set 
up a menu item with the script I showed.

On Saturday, October 26, 2024 at 12:44:21 PM UTC-4 gates...@gmail.com wrote:

> If you’re a mouse user, you can right click -> copy on the UNL at the 
> bottom of the window, underneath the minibuffer.
>
> Jake
>
> On Oct 26, 2024, at 12:06 PM, Thomas Passin  wrote:
>
> 
>
> I keep an outline in which I'm slowly building up bits of information 
> about Leo (and Linux, Python, whatever).  I wanted to find the table of 
> Leo's hooks today.  I didn't want to fish around the various Leo files and 
> web pages trying to find it.  Instead, I knew I had it in my outline so I 
> searched using the Nav tab for "hook".  It found the headline *Table Of 
> Leo's Hooks*. This node contains the link:
>
> unl:gnx://LeoDocs.leo#ekr.20050903074833.1
>
> CTRL-clicking on the link opened the *LeoDocs.leo* outline to the desired 
> node. Beautiful!
>
> I get the target UNL of the node I'm viewing with this code:
>
> """Copy UNL of current position to clipboard."""
> p = c.p
> g.app.gui.replaceClipboardWith(p.get_UNL())
>
> Then I paste the UNL into the outline I'm using to capture these bits of 
> information.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to leo-editor+...@googlegroups.com.
> To view this discussion visit 
> https://groups.google.com/d/msgid/leo-editor/e3fa445b-41aa-473b-981c-2ed1ba853007n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/leo-editor/e3fa445b-41aa-473b-981c-2ed1ba853007n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/098a6a47-3b2d-4cec-82c7-75ec168eb4b5n%40googlegroups.com.

Re: How to check whether audio bytes contain empty noise or actual voice/signal?

2024-10-26 Thread Thomas Passin via Python-list


On 10/25/2024 12:25 PM, marc nicole via Python-list wrote:

Hello Python fellows,

I hope this question is not very far from the main topic of this list, but
I have a hard time finding a way to check whether audio data samples are
containing empty noise or actual significant voice/noise.

I am using PyAudio to collect the sound through my PC mic as follows:

FRAMES_PER_BUFFER = 1024
FORMAT = pyaudio.paInt16
CHANNELS = 1
RATE = 48000
RECORD_SECONDS = 2import pyaudio
audio = pyaudio.PyAudio()
stream = audio.open(format=FORMAT,
 channels=CHANNELS,
 rate=RATE,
 input=True,
 frames_per_buffer=FRAMES_PER_BUFFER,
 input_device_index=2)
data = stream.read(FRAMES_PER_BUFFER)


I want to know whether or not data contains voice signals or empty sound,
To note that the variable always contains bytes (empty or sound) if I print
it.

Is there an straightforward "easy way" to check whether data is filled with
empty noise or that somebody has made noise/spoke?


It's not always so easy.  The Fast Fourier Transform will be your 
friend. The most straightforward way would be to do an autocorrelation 
on the recorded interval, possibly with some pre-filtering to enhance 
the typical vocal frequency range.  If the data is only noise, the 
autocorrelation will show a large signal at point 0 and only small, 
obviously noisy numbers everywhere else. There are practical aspects 
that make things less clear.  For example, voices tend to be spiky and 
erratic so you need to use small intervals to have a better chance of 
getting an interval with a good S/N ratio, but small intervals will have 
a lower signal to noise ratio.


Human speech is produced with various statistical regularities and these 
can sometimes be detected with various means, including the autocorrelation.


You also will need to test-record your entire signal chain because it 
might be producing artifacts that could fool some tests.  And background 
sounds could fool some tests as well.


Here are some Python libraries that could be very helpful:

librosa (I have not worked with this but it sounds right on target);
scipy.signal (I have used scypi but not specifically scipy.signal);
python-speech-features (another I haven't used);
https://python-speech-features.readthedocs.io/en/latest/

Other people will know of others.
--
https://mail.python.org/mailman/listinfo/python-list

Tip - Finding Leo's Documentation More Easily

I keep an outline in which I'm slowly building up bits of information about 
Leo (and Linux, Python, whatever).  I wanted to find the table of Leo's 
hooks today.  I didn't want to fish around the various Leo files and web 
pages trying to find it.  Instead, I knew I had it in my outline so I 
searched using the Nav tab for "hook".  It found the headline *Table Of 
Leo's Hooks*. This node contains the link:

unl:gnx://LeoDocs.leo#ekr.20050903074833.1

CTRL-clicking on the link opened the *LeoDocs.leo* outline to the desired 
node. Beautiful!

I get the target UNL of the node I'm viewing with this code:

"""Copy UNL of current position to clipboard."""
p = c.p
g.app.gui.replaceClipboardWith(p.get_UNL())

Then I paste the UNL into the outline I'm using to capture these bits of 
information.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/e3fa445b-41aa-473b-981c-2ed1ba853007n%40googlegroups.com.

[patch, Fortran, doc] Update descriptions for UNSIGNED


Hello world,

the attached patch adds documentation for the long list of intrinsics
which take UNSIGNED arguments. Checked with "make html", "make pdf" and
"make info".

gcc/fortran/ChangeLog:

* gfortran.texi: Correct reference to make clear that UNSIGNED
will not be part of F202Y.
Other clarifications.
Extend table of intrinsics, add links.
* intrinsic.texi: Add descriptions for UNSIGNED arguments.
* invoke.texi: Add anchor for -funsigned.

OK for trunk?

Best regards

Thomasdiff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 76326e625f8..a20053ed611 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1192,7 +1192,7 @@ extensions.
 @menu
 * Extensions implemented in GNU Fortran::
 * Extensions not implemented in GNU Fortran::
-* Experimental features for Fortran 202Y::
+* Experimental features for future Fortran versions::
 @end menu
 
 
@@ -2702,19 +2702,19 @@ descriptor occurred, use @code{INQUIRE} to get the file position,
 count the characters up to the next @code{NEW_LINE} and then start
 reading from the position marked previously.
 
-@node Experimental features for Fortran 202Y
-@section Experimental features for Fortran 202Y
-@cindex Fortran 202Y
+@node Experimental features for future Fortran versions
+@section Experimental features future Fortran versions
+@cindex Future Fortran versions
 
 GNU Fortran supports some experimental features which have been
 proposed and accepted by the J3 standards committee.  These
 exist to give users a chance to try them out, and to provide
 a reference implementation.
 
-As these features have not been finalized, there is a chance that the
-version in the upcoming standard will differ from what GNU Fortran
-currently implements.  Stability of these implementations is therefore
-not guaranteed.
+As these features have not been included in the worklist for Fortran
+202Y by WG5, there is a chance that a version in any upcoming standard
+will differ from what GNU Fortran currently implements.  These
+features are therefore currently classified as an extension.
 
 @menu
 * Unsigned integers::
@@ -2723,11 +2723,12 @@ not guaranteed.
 @node Unsigned integers
 @subsection Unsigned integers
 @cindex Unsigned integers
-GNU Fortran supports unsigned integers according to
+If the @option{-funsigned} option is given, GNU Fortran supports
+unsigned integers according to
 @uref{https://j3-fortran.org/doc/year/24/24-116.txt, J3/24-116}.  The
-data type is called @code{UNSIGNED}.  For an unsigned type with $n$ bits,
-it implements integer arithmetic modulo @code{2**n}, comparable to the
-@code{unsigned} data type in C.
+data type is called @code{UNSIGNED}.  For an unsigned type with @code{n}
+bits, it implements integer arithmetic modulo @code{2**n}, comparable
+to the @code{unsigned} data type in C.
 
 The data type has @code{KIND} numbers comparable to other Fortran data
 types, which can be selected via the @code{SELECTED_UNSIGNED_KIND}
@@ -2771,31 +2772,75 @@ formatted and unformatted I/O.  For formatted I/O, the @code{B},
 values and values which would overflow are rejected with
 @code{-pedantic}.
 
-As of now, the following intrinsics take unsigned arguments:
+The following intrinsics take unsigned arguments:
 @itemize @bullet
-@item @code{BLT}, @code{BLE}, @code{BGE} and @code{BGT}. These intrinsics
-  are actually redundant because comparison operators could be used
-  directly.
-@item @code{IAND}, @code{IOR}, @code{IEOR} and @code{NOT}
-@item @code{BIT_SIZE}, @code{DIGITS} and @code{HUGE}
-@item @code{DSHIFTL} and @code{DSHIFTR}
-@item @code{IBCLR}, @code{IBITS} and @code{IBSET}
-@item @code{MIN} and @code{MAX}
-@item @code{ISHFT}, @code{ISHFTC}, @code{SHIFTL}, @code{SHIFTR} and
-  @code{SHIFTA}.
-@item @code{MERGE_BITS}
-@item @code{MOD} and @code{MODULO}
-@item @code{MVBITS}
-@item @code{RANGE}
-@item @code{TRANSFER}
-@item @code{SUM}, @code{PRODUCT}, @code{MATMUL} and @code{DOT_PRODUCT}
-@item @code{IANY}, @code{IALL} and @code{IPARITY}
-@item @code{RANDOM_NUMBER}
-@item @code{CSHIFT} and @code{EOSHIFT}
-@item @code{FINDLOC}
-@item @code{MAXVAL} and @code{MINVAL}
-@item @code{MAXLOC} and @code{MINLOC}.
+@item @code{BGE}, @pxref{BGE}
+@item @code{BGT}, @pxref{BGT}
+@item @code{BIT_SIZE}, @pxref{BIT_SIZE}
+@item @code{BLE}, @pxref{BLE}
+@item @code{BLT}, @pxref{BLT}
+@item @code{CSHIFT}, @pxref{CSHIFT}
+@item @code{DIGITS}, @pxref{DIGITS}
+@item @code{DOT_PRODUCT}, @pxref{DOT_PRODUCT}
+@item @code{DSHIFTL}, @pxref{DSHIFTL}
+@item @code{DSHIFTR}, @pxref{DSHIFTR}
+@item @code{EOSHIFT}, @pxref{EOSHIFT}
+@item @code{FINDLOC}, @pxref{FINDLOC}
+@item @code{HUGE}, @pxref{HUGE}
+@item @code{IALL}, @pxref{IALL}
+@item @code{IAND}, @pxref{IAND}
+@item @code{IANY}, @pxref{IANY}
+@item @code{IBCLR}, @pxref{IBCLR}
+@item @code{IBITS}, @pxref{IBITS}
+@item @code{IBSET}, @pxref{IBSET}
+@item @code{IEOR}, @pxref{IEOR}
+@item @code{IOR}, @pxref{IOR}
+@item @code{IPARITY},

[patch, Fortran, doc] Update descriptions for UNSIGNED


Hello world,

the attached patch adds documentation for the long list of intrinsics
which take UNSIGNED arguments. Checked with "make html", "make pdf" and
"make info".

gcc/fortran/ChangeLog:

* gfortran.texi: Correct reference to make clear that UNSIGNED
will not be part of F202Y.
Other clarifications.
Extend table of intrinsics, add links.
* intrinsic.texi: Add descriptions for UNSIGNED arguments.
* invoke.texi: Add anchor for -funsigned.

OK for trunk?

Best regards

Thomasdiff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 76326e625f8..a20053ed611 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1192,7 +1192,7 @@ extensions.
 @menu
 * Extensions implemented in GNU Fortran::
 * Extensions not implemented in GNU Fortran::
-* Experimental features for Fortran 202Y::
+* Experimental features for future Fortran versions::
 @end menu
 
 
@@ -2702,19 +2702,19 @@ descriptor occurred, use @code{INQUIRE} to get the file position,
 count the characters up to the next @code{NEW_LINE} and then start
 reading from the position marked previously.
 
-@node Experimental features for Fortran 202Y
-@section Experimental features for Fortran 202Y
-@cindex Fortran 202Y
+@node Experimental features for future Fortran versions
+@section Experimental features future Fortran versions
+@cindex Future Fortran versions
 
 GNU Fortran supports some experimental features which have been
 proposed and accepted by the J3 standards committee.  These
 exist to give users a chance to try them out, and to provide
 a reference implementation.
 
-As these features have not been finalized, there is a chance that the
-version in the upcoming standard will differ from what GNU Fortran
-currently implements.  Stability of these implementations is therefore
-not guaranteed.
+As these features have not been included in the worklist for Fortran
+202Y by WG5, there is a chance that a version in any upcoming standard
+will differ from what GNU Fortran currently implements.  These
+features are therefore currently classified as an extension.
 
 @menu
 * Unsigned integers::
@@ -2723,11 +2723,12 @@ not guaranteed.
 @node Unsigned integers
 @subsection Unsigned integers
 @cindex Unsigned integers
-GNU Fortran supports unsigned integers according to
+If the @option{-funsigned} option is given, GNU Fortran supports
+unsigned integers according to
 @uref{https://j3-fortran.org/doc/year/24/24-116.txt, J3/24-116}.  The
-data type is called @code{UNSIGNED}.  For an unsigned type with $n$ bits,
-it implements integer arithmetic modulo @code{2**n}, comparable to the
-@code{unsigned} data type in C.
+data type is called @code{UNSIGNED}.  For an unsigned type with @code{n}
+bits, it implements integer arithmetic modulo @code{2**n}, comparable
+to the @code{unsigned} data type in C.
 
 The data type has @code{KIND} numbers comparable to other Fortran data
 types, which can be selected via the @code{SELECTED_UNSIGNED_KIND}
@@ -2771,31 +2772,75 @@ formatted and unformatted I/O.  For formatted I/O, the @code{B},
 values and values which would overflow are rejected with
 @code{-pedantic}.
 
-As of now, the following intrinsics take unsigned arguments:
+The following intrinsics take unsigned arguments:
 @itemize @bullet
-@item @code{BLT}, @code{BLE}, @code{BGE} and @code{BGT}. These intrinsics
-  are actually redundant because comparison operators could be used
-  directly.
-@item @code{IAND}, @code{IOR}, @code{IEOR} and @code{NOT}
-@item @code{BIT_SIZE}, @code{DIGITS} and @code{HUGE}
-@item @code{DSHIFTL} and @code{DSHIFTR}
-@item @code{IBCLR}, @code{IBITS} and @code{IBSET}
-@item @code{MIN} and @code{MAX}
-@item @code{ISHFT}, @code{ISHFTC}, @code{SHIFTL}, @code{SHIFTR} and
-  @code{SHIFTA}.
-@item @code{MERGE_BITS}
-@item @code{MOD} and @code{MODULO}
-@item @code{MVBITS}
-@item @code{RANGE}
-@item @code{TRANSFER}
-@item @code{SUM}, @code{PRODUCT}, @code{MATMUL} and @code{DOT_PRODUCT}
-@item @code{IANY}, @code{IALL} and @code{IPARITY}
-@item @code{RANDOM_NUMBER}
-@item @code{CSHIFT} and @code{EOSHIFT}
-@item @code{FINDLOC}
-@item @code{MAXVAL} and @code{MINVAL}
-@item @code{MAXLOC} and @code{MINLOC}.
+@item @code{BGE}, @pxref{BGE}
+@item @code{BGT}, @pxref{BGT}
+@item @code{BIT_SIZE}, @pxref{BIT_SIZE}
+@item @code{BLE}, @pxref{BLE}
+@item @code{BLT}, @pxref{BLT}
+@item @code{CSHIFT}, @pxref{CSHIFT}
+@item @code{DIGITS}, @pxref{DIGITS}
+@item @code{DOT_PRODUCT}, @pxref{DOT_PRODUCT}
+@item @code{DSHIFTL}, @pxref{DSHIFTL}
+@item @code{DSHIFTR}, @pxref{DSHIFTR}
+@item @code{EOSHIFT}, @pxref{EOSHIFT}
+@item @code{FINDLOC}, @pxref{FINDLOC}
+@item @code{HUGE}, @pxref{HUGE}
+@item @code{IALL}, @pxref{IALL}
+@item @code{IAND}, @pxref{IAND}
+@item @code{IANY}, @pxref{IANY}
+@item @code{IBCLR}, @pxref{IBCLR}
+@item @code{IBITS}, @pxref{IBITS}
+@item @code{IBSET}, @pxref{IBSET}
+@item @code{IEOR}, @pxref{IEOR}
+@item @code{IOR}, @pxref{IOR}
+@item @code{IPARITY},

Bug#1086004: ITS: perforate

2024-10-26 Thread Reuben Thomas

On Thu, 24 Oct 2024 at 18:03, Andreas Tille  wrote:

>
> I'm interested in salvaging your package perforate, in accordance with
> the Package Salvaging procedure outlined in the Developers Reference[1].
>

That would be great!

I have done quite a bit of work on this package that has not been released
in Debian, largely, I suspect, because it involves a name change.

See https://github.com/rrthomas/finddup

The main points are that a) there was never a program called 'perforate',
b) the program 'zum' that did the "perforating" is now otiose, as file
systems and cp between them take care of this functionality, and so c) the
useful functionality left in the package was mainly the 'finddup' program,
which I have updated, along with the minor utility 'findstrip', and the
'findcore' script which I've added to my version of the package.

-- 
https://rrt.sc3d.org

[kommit] [Bug 495351] kommitdiff

2024-10-26 Thread Thomas Braun

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

--- Comment #1 from Thomas Braun  ---
Crashes in a X11 Session as well: 

Application: Kommit (kommit), signal: Segmentation fault


This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) [answered N; input not from
terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.

warning: Can't open file anon_inode:i915.gem which was expanded to
anon_inode:i915.gem during file-backed mapping note processing
[New LWP 29979]
[New LWP 29981]
[New LWP 29982]
[New LWP 29983]
[New LWP 29980]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/kommit diff'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x75d44f6a53f4 in ?? () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x75d448faea00 (LWP 29979))]
Cannot QML trace cores :(
/usr/share/drkonqi/gdb/python/gdb_preamble/preamble.py:516: DeprecationWarning:
datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in
a future version. Use timezone-aware objects to represent datetimes in UTC:
datetime.datetime.fromtimestamp(timestamp, datetime.UTC).
  boot_time =
datetime.utcfromtimestamp(psutil.boot_time()).strftime('%Y-%m-%dT%H:%M:%S')
/usr/share/drkonqi/gdb/python/gdb_preamble/preamble.py:533: DeprecationWarning:
datetime.datetime.utcnow() is deprecated and scheduled for removal in a future
version. Use timezone-aware objects to represent datetimes in UTC:
datetime.datetime.now(datetime.UTC).
  'timestamp': datetime.utcnow().isoformat(),
[Current thread is 1 (Thread 0x75d448faea00 (LWP 29979))]

Thread 5 (Thread 0x75d448a006c0 (LWP 29980)):
#0  0x75d44f71abb0 in ppoll () from /usr/lib/libc.so.6
#1  0x75d44ea81227 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x75d44ea1da55 in g_main_context_iteration () from
/usr/lib/libglib-2.0.so.0
#3  0x75d44fbbf71d in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/libQt6Core.so.6
#4  0x75d44f964566 in
QEventLoop::exec(QFlags) () from
/usr/lib/libQt6Core.so.6
#5  0x75d44fa57072 in QThread::exec() () from /usr/lib/libQt6Core.so.6
#6  0x75d44ef7379e in ?? () from /usr/lib/libQt6DBus.so.6
#7  0x75d44fad840f in ?? () from /usr/lib/libQt6Core.so.6
#8  0x75d44f6a339d in ?? () from /usr/lib/libc.so.6
#9  0x75d44f72849c in ?? () from /usr/lib/libc.so.6

Thread 4 (Thread 0x75d4414006c0 (LWP 29983)):
#0  0x75d44f69fa19 in ?? () from /usr/lib/libc.so.6
#1  0x75d44f6a2479 in pthread_cond_wait () from /usr/lib/libc.so.6
#2  0x75d4398ced6e in ?? () from /usr/lib/libgallium-24.2.5-arch1.1.so
#3  0x75d4398ab77c in ?? () from /usr/lib/libgallium-24.2.5-arch1.1.so
#4  0x75d4398cec9d in ?? () from /usr/lib/libgallium-24.2.5-arch1.1.so
#5  0x75d44f6a339d in ?? () from /usr/lib/libc.so.6
#6  0x75d44f72849c in ?? () from /usr/lib/libc.so.6

Thread 3 (Thread 0x75d441e006c0 (LWP 29982)):
#0  0x75d44f69fa19 in ?? () from /usr/lib/libc.so.6
#1  0x75d44f6a2479 in pthread_cond_wait () from /usr/lib/libc.so.6
#2  0x75d4398ced6e in ?? () from /usr/lib/libgallium-24.2.5-arch1.1.so
#3  0x75d4398ab77c in ?? () from /usr/lib/libgallium-24.2.5-arch1.1.so
#4  0x75d4398cec9d in ?? () from /usr/lib/libgallium-24.2.5-arch1.1.so
#5  0x75d44f6a339d in ?? () from /usr/lib/libc.so.6
#6  0x75d44f72849c in ?? () from /usr/lib/libc.so.6

Thread 2 (Thread 0x75d443e006c0 (LWP 29981)):
#0  0x75d44f71a63d in poll () from /usr/lib/libc.so.6
#1  0x75d44d67d20b in ?? () from /usr/lib/libxcb.so.1
#2  0x75d44d67ef3d in xcb_wait_for_event () from /usr/lib/libxcb.so.1
#3  0x75d448bacc39 in ?? () from
/usr/lib/qt6/plugins/platforms/../../../libQt6XcbQpa.so.6
#4  0x75d44fad840f in ?? () from /usr/lib/libQt6Core.so.6
#5  0x75d44f6a339d in ?? () from /usr/lib/libc.so.6
#6  0x75d44f72849c in ?? () from /usr/lib/libc.so.6

Thread 1 (Thread 0x75d448faea00 (LWP 29979)):
[KCrash Handler]
#4  0x75d44f8cb766 in ?? () from /usr/lib/libQt6Core.so.6
#5  0x75d44f961591 in QMetaObject::invokeMethodImpl(QObject*, char const*,
Qt::ConnectionType, long long, void const* const*, char const* const*,
QtPrivate::QMetaTypeInterface const* const*) () from /usr/lib/libQt6Core.so.6
#6  0x75d45124ca91 in ?? () from /usr/lib/libkommitgui.so.0
#7  0x61e2055705ae in ?? ()
#8  0x75d44f634e08 in ?? () from /usr/lib/libc.so.6
#9  0x75d44f634ecc in __libc_start_main () from /usr/lib/libc.so.6
#10 0x61e2055706d5 in ?? ()

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

Bug#1082989: dictionaries-common: Please update debian-ispell.el to support Enchant

2024-10-26 Thread Reuben Thomas

On Tue, 8 Oct 2024 at 08:46, Agustin Martin  wrote:

> >
> >
> > > I have a rough first cut that does not yet address above issue. Will
> think
> > > a bit more about this. spellchecker priorities will be the same as in
> FSF
> > > Emacs.
> > >
> >
> > I'll be very happy to test what you come up with.
>
> I have pushed to https://salsa.debian.org/debian/dictionaries-common.git
> a couple of commits to deal with this. Seem to work reasonably here.
>

I'm sorry that I didn't get to this sooner. I have now done a quick test by
installing dictionaries-common 1.30.1 on my Ubuntu 24.04 system (so,
apologies if I'm messing things up with my mismatched system), and I get
the same error as before when I try to spellcheck with ispell, caused by a
nil first entry in the argument to debian-ispell-build-startup-menu.

I will try to look into this more when I can find a moment (as quite
possibly it's something to do with my setup), but if you have any hints,
I'd be happy to hear them.

One other thing: in recent versions, Enchant is rather more liberal about
the format of language tags it allows (they need not be just locales). I
was wondering where "castellano" comes from: when I install aspell-es,
`aspell dump dicts` does not list it.

-- 
https://rrt.sc3d.org

Re: Engineering Notebook - Jupytext The Leonine Way

I see that I forgot that the Python code in a Jupytext file is already 
uncommented (shucks, I knew that yesterday!) So we do get syntax 
highlighting as is. All the rest still applies.

On Saturday, October 26, 2024 at 9:03:34 AM UTC-4 Thomas Passin wrote:

> This is a long post so I'm putting a summary at the start.
>
> 1. Leo can provide a very good way for a user to create and edit Juptyer 
> notebooks.
> 2. The exploratory work for @jupytext files does not provide a proper 
> Leonine experience.
> 3. The usual Leo approach is weak when it comes to working with 
> documentation, and documentation mixed with code, in contrast to progams, 
> itemized lists, and the like where Leo is strong.
> 4. This weaknesss can be overcome and there is a discussion of how and 
> why, and some design suggestions.
>
> There has been a flurry of activity in the last few weeks to add an 
> ability for working with Jupyter notebooks by means of an intermediate file 
> format.  That format is provided by the JupyText program.  However, in the 
> rush no one seems to have thought much about what Leo can bring to the 
> table, or why anyone would want to use Leo for this purpose, compared let's 
> say with the Jupyter plugin for Visual Studio Code, which seems very good 
> and very readable to me.
>
> For those who don't know yet, a Jupyter notebook's file format is JSON. 
>  JSON was designed to interchange data, including program structures. It 
> was not designed for documentation or readability. Jupyter notebooks 
> contain a sequence of "cells" - basically nodes - that are either Markdown 
> text or code cells. There is no other structure. Jupytext's contribution is 
> to flatten the nested JSON data structure to a flat text format with what 
> amounts to sentinels - each line is commented out, and there are a few 
> specially-formatted comments. One of these special comment lines marks the 
> start of a Markdown cell, and another marks the start of a Python cell.
>
> Leo is very strong in these areas:
>
> 1. Structure is indicated by and can be changed using the outline;
>
> 2. Only the contents of a single node are visible and editable at one 
> time.  This is excellent for concentrating on programming and itemized 
> lists of all kinds.
>
> 3. Any markup such as Leo's sentinels that are needed to support 
> structure or other Leo features are hidden from the user.  There's hardly 
> any visual clutter. IMO this is a crucial feature that Leo offers.  It 
> makes writing code to save and restore outlines and external files very 
> complicated, but the user doesn't need to know about that.
>
> Leo is not nearly as capable in supporting writing and documentation. 
> That's because even though structure is important, it's also important to 
> be able to see and edit the flow of the document from node to node and how 
> nearby parts work together. An example is creating documentation using the 
> rst3 command and Sphinx.  The mechanics of this process are excellent but 
> doing editing beyond the node level requires a lot of mental effort and 
> trial runs with Sphinx.  The Viewrendered3 plugin is designed to help with 
> this problem by letting the user view an entire subtree.
>
> Jupyter notebooks are serial combinations of documentation and code. 
> Basically they are a limited form of "literate programming".  The code 
> cells are usually small enough that they don't need to be structured.  They 
> are displayed by a Jupyter-viewing program in a clean, very readable way.
>
> The Jupytext work over the last few weeks presents the user with a direct 
> view of the Jupytext-formatted file, sentinels, embedded comments, and all. 
>  A user has to hand-edit the file while being distracted by the extra 
> markup and not being able to see the flow of the parts one into another. 
>  Yes, parts can be moved around and navigated to using the outline, but the 
> editing experience is inferior.  There is also no syntax highlighting for 
> code nodes - since the code is all commented out - nor can even rudimentary 
> syntax checks be carried out.  The appearance of the document as it would 
> be viewed in a Jupyter program - well, it is unknown until the file is 
> saved to the .ipynb form and reloaded into Jupyter.
>
> The Leonine Way
> --
> 1.  Leo should present a view of a Jupyter notebook file to the user 
> without sentinels or visual clutter, just like it does with other external 
> file types.
>
> 2. Leo should be able to recreate the file's structure on reloading, or at 
> least a close approximation to it.
>
> 3. Code cells should be syntax-highlighted and preferably able to be at

Engineering Notebook - Jupytext The Leonine Way

This is a long post so I'm putting a summary at the start.

1. Leo can provide a very good way for a user to create and edit Juptyer 
notebooks.
2. The exploratory work for @jupytext files does not provide a proper 
Leonine experience.
3. The usual Leo approach is weak when it comes to working with 
documentation, and documentation mixed with code, in contrast to progams, 
itemized lists, and the like where Leo is strong.
4. This weaknesss can be overcome and there is a discussion of how and why, 
and some design suggestions.

There has been a flurry of activity in the last few weeks to add an ability 
for working with Jupyter notebooks by means of an intermediate file format. 
 That format is provided by the JupyText program.  However, in the rush no 
one seems to have thought much about what Leo can bring to the table, or 
why anyone would want to use Leo for this purpose, compared let's say with 
the Jupyter plugin for Visual Studio Code, which seems very good and very 
readable to me.

For those who don't know yet, a Jupyter notebook's file format is JSON. 
 JSON was designed to interchange data, including program structures. It 
was not designed for documentation or readability. Jupyter notebooks 
contain a sequence of "cells" - basically nodes - that are either Markdown 
text or code cells. There is no other structure. Jupytext's contribution is 
to flatten the nested JSON data structure to a flat text format with what 
amounts to sentinels - each line is commented out, and there are a few 
specially-formatted comments. One of these special comment lines marks the 
start of a Markdown cell, and another marks the start of a Python cell.

Leo is very strong in these areas:

1. Structure is indicated by and can be changed using the outline;

2. Only the contents of a single node are visible and editable at one 
time.  This is excellent for concentrating on programming and itemized 
lists of all kinds.

3. Any markup such as Leo's sentinels that are needed to support 
structure or other Leo features are hidden from the user.  There's hardly 
any visual clutter. IMO this is a crucial feature that Leo offers.  It 
makes writing code to save and restore outlines and external files very 
complicated, but the user doesn't need to know about that.

Leo is not nearly as capable in supporting writing and documentation. 
That's because even though structure is important, it's also important to 
be able to see and edit the flow of the document from node to node and how 
nearby parts work together. An example is creating documentation using the 
rst3 command and Sphinx.  The mechanics of this process are excellent but 
doing editing beyond the node level requires a lot of mental effort and 
trial runs with Sphinx.  The Viewrendered3 plugin is designed to help with 
this problem by letting the user view an entire subtree.

Jupyter notebooks are serial combinations of documentation and code. 
Basically they are a limited form of "literate programming".  The code 
cells are usually small enough that they don't need to be structured.  They 
are displayed by a Jupyter-viewing program in a clean, very readable way.

The Jupytext work over the last few weeks presents the user with a direct 
view of the Jupytext-formatted file, sentinels, embedded comments, and all. 
 A user has to hand-edit the file while being distracted by the extra 
markup and not being able to see the flow of the parts one into another. 
 Yes, parts can be moved around and navigated to using the outline, but the 
editing experience is inferior.  There is also no syntax highlighting for 
code nodes - since the code is all commented out - nor can even rudimentary 
syntax checks be carried out.  The appearance of the document as it would 
be viewed in a Jupyter program - well, it is unknown until the file is 
saved to the .ipynb form and reloaded into Jupyter.

The Leonine Way
--
1.  Leo should present a view of a Jupyter notebook file to the user 
without sentinels or visual clutter, just like it does with other external 
file types.

2. Leo should be able to recreate the file's structure on reloading, or at 
least a close approximation to it.

3. Code cells should be syntax-highlighted and preferably able to be at 
least syntax-checkable.

4. Code execution would be a bonus but not required.

5. The user should need to know a minimum of special forms such as 
directives or other special markup features, and if there are any they 
should have a form similar to other Leo forms.

6. There should be a way to show a view of adjacent or nearby nodes so that 
the user can make sure they work together as intended. Showing a fully 
rendered view of nodes' Markdown is a desirable bonus to avoid 
round-tripping to Jupyter.

7. There should be an easy way to extend the file handling and rendering 
capabilities to use other programming languages besides Python.

6. The process of converting, importing, and exporting the files should be

Re: Leo's jupytext code works!

Don't get too set on the way @jupytext works right now.  It's not actually 
very Leonistic.  We can do better.  I will talk about why I say that and 
how to do better in an upcoming post.

On Saturday, October 26, 2024 at 12:42:12 AM UTC-4 iamap...@gmail.com wrote:

> Well, yes, execution ability will be limited, that's right. VR3 won't know 
>> about magics, and all the needed libraries will have to be imported in the 
>> outline. Also graphics that Jupyter would embed won't work.  So execution 
>> capabilities would be limited, but there will be some outlines that could 
>> be executed.
>
>
> I already saw your screenshot in the PR 
> . 
> I like it! You and Edward are awesome, this feature will save me a lot of 
> time in future. Once @jupytext is stable I will definitely show off our 
> usage to the jupytext guys :-D Hahahaha
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/437849dd-1697-49b2-a594-6a78a0a0aea1n%40googlegroups.com.

[gentoo-commits] repo/gentoo:master commit in: dev-libs/libzia/

2024-10-26 Thread Thomas Beierlein

commit: 6f9ea6f85c11e626a239368274238322fd5a97fd
Author: Thomas Beierlein  gentoo  org>
AuthorDate: Sat Oct 26 09:38:44 2024 +
Commit:     Thomas Beierlein  gentoo  org>
CommitDate: Sat Oct 26 09:39:55 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f9ea6f8

dev-libs/libzia: add 4.64

Signed-off-by: Thomas Beierlein  gentoo.org>

 dev-libs/libzia/Manifest   |  1 +
 dev-libs/libzia/libzia-4.64.ebuild | 54 ++
 2 files changed, 55 insertions(+)

diff --git a/dev-libs/libzia/Manifest b/dev-libs/libzia/Manifest
index 9a95b829a418..5cd9d573ab4e 100644
--- a/dev-libs/libzia/Manifest
+++ b/dev-libs/libzia/Manifest
@@ -1 +1,2 @@
 DIST libzia-4.61.tar.gz 649569 BLAKE2B 
992f7d7a4f2a7497d490a32b04c2f67e45aef361d4f55bd24ab873b3a422f2bd2a23501c275d6771459b5ebe5d169fc28123a4fd328f0977a639fa92991ba62b
 SHA512 
210104a16846b4bbae51e91cd88428cb8b6f487a6bc234a8a7351d03865ff968bf75d102dfe5657f9fc1c181e2071a4e4ab6be0e22da277188f3ab9752ea789d
+DIST libzia-4.64.tar.gz 655073 BLAKE2B 
7ec3397565d441d7f820bda9b73e1051031e30bea6111e28cc2073cd1ea49be237c35c1eb358671b1930de74e0e2f3ff4beb476676ce9b9bef608a9f39da5ca3
 SHA512 
5e520fb1e1782e919c727e6056ae1e979c9774e9a994267c9eabe86f4a5b9c62d11639b59735e236cc36fa42e319418e4cbe12a2e41c47d5040ed6c1d7929192

diff --git a/dev-libs/libzia/libzia-4.64.ebuild 
b/dev-libs/libzia/libzia-4.64.ebuild
new file mode 100644
index ..7bc214eded10
--- /dev/null
+++ b/dev-libs/libzia/libzia-4.64.ebuild
@@ -0,0 +1,54 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+inherit autotools flag-o-matic
+
+DESCRIPTION="Platform abstraction code for tucnak package"
+HOMEPAGE="http://tucnak.nagano.cz";
+SRC_URI="http://tucnak.nagano.cz/${P}.tar.gz";
+
+LICENSE="GPL-2"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+IUSE="ftdi"
+
+RDEPEND="dev-libs/glib:2
+   x11-libs/gtk+:3
+   media-libs/libsdl2
+   media-libs/sdl2-ttf
+   media-libs/libpng:=
+   net-libs/gnutls:=
+   ftdi? ( dev-embedded/libftdi:1 )
+   elibc_musl? ( sys-libs/libunwind )"
+DEPEND="${RDEPEND}"
+BDEPEND="virtual/pkgconfig"
+
+MAKEOPTS+=" -j1"
+
+src_prepare() {
+   eapply_user
+   sed -i -e "s/docsdir/#docsdir/g" \
+   -e "s/docs_/#docs_/g" Makefile.am || die
+
+   # fix build for MUSL (bugs #832235, 935544)
+   if use elibc_musl ; then
+   sed -i -e "s/zstr.h>/zstr.h>\\n#include /" 
src/zbfd.c || die
+   sed -i -e "s/ backtrace(/ unw_backtrace(/" src/zbfd.c || die
+   fi
+   eautoreconf
+}
+
+src_configure() {
+   use elibc_musl && append-libs -lunwind
+   econf \
+   $(use_with ftdi) --with-sdl \
+   --with-png --without-bfd \
+   --disable-static
+}
+
+src_install() {
+   emake DESTDIR="${D}" install
+   find "${D}" -name '*.la' -type f -delete || die
+}

[gentoo-commits] repo/gentoo:master commit in: media-radio/tucnak/

2024-10-26 Thread Thomas Beierlein

commit: 5379725baeeba9d35c1ab73fd53a4e8385837ccf
Author: Thomas Beierlein  gentoo  org>
AuthorDate: Sat Oct 26 09:39:35 2024 +
Commit:     Thomas Beierlein  gentoo  org>
CommitDate: Sat Oct 26 09:39:55 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5379725b

media-radio/tucnak: add 4.64

Signed-off-by: Thomas Beierlein  gentoo.org>

 media-radio/tucnak/Manifest   |  1 +
 media-radio/tucnak/tucnak-4.64.ebuild | 74 +++
 2 files changed, 75 insertions(+)

diff --git a/media-radio/tucnak/Manifest b/media-radio/tucnak/Manifest
index 0fb5b9faae42..612bf274c469 100644
--- a/media-radio/tucnak/Manifest
+++ b/media-radio/tucnak/Manifest
@@ -1 +1,2 @@
 DIST tucnak-4.61.tar.gz 6824381 BLAKE2B 
f995271f309d24725993bd243ade28744a81d5ab80f994dd3425336930bcd8212433f17d682575d3725243c0e1fc84510e9bd063a6b5372158d3a88558898e34
 SHA512 
67d17da2a321492c8c38f2207570631851122fe2615f7cc20716ad0906b0fc2422e414e0be91fdfad2474b08d20c4c05c0d2aec9ad2d1d6afc3450af0d9eeb62
+DIST tucnak-4.64.tar.gz 6765553 BLAKE2B 
e093080db4e019a91cc8e95c4262bad039a2a158c9823337cb9e12691de18c6d0ec54aeb1d21ff7bb8c8d6b7b63e8761bb9a3078d76a4f9a98093b6d92d43d22
 SHA512 
9aa85fc7669083aadc2caec2577f0d65cc342e041c34bc4f9e8f3315d867eb99cf4296e25d83169d2b5b5d3f33c230922882312ea416eb3dce4f4fc1f47ffed0

diff --git a/media-radio/tucnak/tucnak-4.64.ebuild 
b/media-radio/tucnak/tucnak-4.64.ebuild
new file mode 100644
index ..44d4452c95e0
--- /dev/null
+++ b/media-radio/tucnak/tucnak-4.64.ebuild
@@ -0,0 +1,74 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+inherit autotools flag-o-matic
+
+DESCRIPTION="Amateur Radio VHF Contest Logbook"
+HOMEPAGE="http://tucnak.nagano.cz";
+SRC_URI="http://tucnak.nagano.cz/${P}.tar.gz";
+
+LICENSE="GPL-2"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+IUSE="alsa fftw gpm hamlib portaudio rtlsdr suid"
+
+RDEPEND="dev-libs/glib:2
+   ~dev-libs/libzia-4.64
+   media-libs/libsndfile
+   media-libs/libsdl2
+   alsa? ( media-libs/alsa-lib )
+   fftw? ( sci-libs/fftw:3.0= )
+   gpm? ( sys-libs/gpm )
+   hamlib? ( media-libs/hamlib:= )
+   portaudio? ( media-libs/portaudio )
+   rtlsdr? ( net-wireless/rtl-sdr )"
+DEPEND="${RDEPEND}
+   virtual/pkgconfig"
+
+src_prepare() {
+   eapply_user
+   # fix destop file
+   sed -i -e "s/HamRadio/HamRadio;/" share/applications/tucnak.desktop || 
die
+   # fix doc install path
+   sed -i -e "s/docsdir/# docsdir/" \
+   -e "s/docs_DATA =/# docs_DATA/" \
+   -e "s/EXTRA_DIST =/# EXTRA_DIST =/" Makefile.am doc/Makefile.am 
|| die
+   eautoreconf
+}
+
+src_configure() {
+   append-ldflags -L/usr/$(get_libdir)/hamlib
+   econf $(use_with alsa) \
+   $(use_with gpm) \
+   $(use_with hamlib) \
+   $(use_with fftw fftw3) \
+   $(use_with portaudio) \
+   $(use_with rtlsdr) \
+   --without-hidapi
+}
+
+src_install() {
+   emake DESTDIR="${D}" install
+   dodoc AUTHORS ChangeLog doc/NAVOD.pdf
+   if use suid ; then
+   fperms 4711 /usr/bin/soundwrapper
+   fi
+}
+
+pkg_postinst() {
+   elog "In order to use sound with tucnak add yourself to the 'audio' 
group"
+   elog "and to key your rig via the parport add yourself to the 'lp' 
group"
+   elog ""
+   elog "tucnak can be used with the following additional packages:"
+   elog " media-radio/cwdaemon  : Morse output via code cwdaemon"
+   elog " (No need to recompile)"
+   if use suid ; then
+   ewarn "You have choosen to install the little helper program 
'soundwrapper'"
+   ewarn "setuid by setting USE=suid. That helper is only needed 
if you"
+   ewarn "want to use morse sidetone output via the PC speaker."
+   ewarn ""
+   ewarn "While the helper should be safe by design be aware that 
setting"
+   ewarn "any program setuid is a security risk."
+   fi
+}

Re: [PATCH 04/36] next-cube: remove cpu parameter from next_scsi_init()

Am Wed, 23 Oct 2024 09:58:20 +0100
schrieb Mark Cave-Ayland :

> The parameter is not used.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/m68k/next-cube.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Thomas Huth

Re: [PATCH 03/36] next-cube: remove overlap between next.dma and next.mmio memory regions

Am Wed, 23 Oct 2024 09:58:19 +0100
schrieb Mark Cave-Ayland :

> Change the start of the next.mmio memory region so that it follows on directly
> after the next.dma memory region, adjusting the address offsets in
> next_mmio_read() and next_mmio_write() accordingly.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/m68k/next-cube.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/hw/m68k/next-cube.c b/hw/m68k/next-cube.c
> index 4e8e55a8bd..e1d94c1ce0 100644
> --- a/hw/m68k/next-cube.c
> +++ b/hw/m68k/next-cube.c
> @@ -266,23 +266,23 @@ static uint64_t next_mmio_read(void *opaque, hwaddr 
> addr, unsigned size)
>  uint64_t val;
>  
>  switch (addr) {
> -case 0x7000:
> +case 0x2000:
>  /* DPRINTF("Read INT status: %x\n", s->int_status); */
>  val = s->int_status;
>  break;
>  
> -case 0x7800:
> +case 0x2800:
>  DPRINTF("MMIO Read INT mask: %x\n", s->int_mask);
>  val = s->int_mask;
>  break;
>  
> -case 0xc000 ... 0xc003:
> -val = extract32(s->scr1, (4 - (addr - 0xc000) - size) << 3,
> +case 0x7000 ... 0x7003:
> +val = extract32(s->scr1, (4 - (addr - 0x7000) - size) << 3,
>  size << 3);
>  break;
>  
> -case 0xd000 ... 0xd003:
> -val = extract32(s->scr2, (4 - (addr - 0xd000) - size) << 3,
> +case 0x8000 ... 0x8003:
> +val = extract32(s->scr2, (4 - (addr - 0x8000) - size) << 3,
>  size << 3);
>  break;
>  
> @@ -301,25 +301,25 @@ static void next_mmio_write(void *opaque, hwaddr addr, 
> uint64_t val,
>  NeXTPC *s = NEXT_PC(opaque);
>  
>  switch (addr) {
> -case 0x7000:
> +case 0x2000:
>  DPRINTF("INT Status old: %x new: %x\n", s->int_status,
>  (unsigned int)val);
>  s->int_status = val;
>  break;
>  
> -case 0x7800:
> +case 0x2800:
>  DPRINTF("INT Mask old: %x new: %x\n", s->int_mask, (unsigned 
> int)val);
>  s->int_mask  = val;
>  break;

Could you please add comments at the end of the "case" lines, stating which
mmio addresses are handled in each case? Otherwise, it's harder to grep for
certain addresses later. E.g:

case 0x2800: /* 0x2007800 */

> @@ -1000,7 +1000,7 @@ static void next_cube_init(MachineState *machine)
>  sysbus_create_simple(TYPE_NEXTFB, 0x0B00, NULL);
>  
>  /* MMIO */
> -sysbus_mmio_map(SYS_BUS_DEVICE(pcdev), 0, 0x0200);
> +sysbus_mmio_map(SYS_BUS_DEVICE(pcdev), 0, 0x02005000);

Why 0x02005000 and not directly 0x02007000 ?

I think there is another range at 0x02006000 related to the ethernet
controller, so directly going with 0x02007000 might cause less friction
later when we add the NIC?

 Thanks,
  Thomas

Re: [PATCH 01/36] next-cube: fix up compilation when DEBUG_NEXT is enabled

Am Wed, 23 Oct 2024 09:58:17 +0100
schrieb Mark Cave-Ayland :

> These were accidentally introduced by my last series.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/m68k/next-cube.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Reviewed-by: Thomas Huth

Re: [PATCH 02/36] next-cube: remove 0x14020 dummy value from next_mmio_read()

Am Wed, 23 Oct 2024 09:58:18 +0100
schrieb Mark Cave-Ayland :

> This is a dummy value for the SCSI CSR which appears to have no effect when
> removed. Eventually the reads/writes to this register will be directed
> towards the WIP implementations in next_scr_readfn() and next_scr_writefn().
> 
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/m68k/next-cube.c | 4 
>  1 file changed, 4 deletions(-)

Reviewed-by: Thomas Huth

Re: Head up: PR #4121 (in devel) may cause problems

I tested all the layouts in a Linux VM too and they all worked as 
intended.  All except the one where I had a typo.  Are you sure that didn't 
happen to you?  Which layout had you specified, and what did you get?

On Friday, October 25, 2024 at 5:07:12 PM UTC-4 Edward K. Ream wrote:

> On Friday, October 25, 2024 at 2:04:24 PM UTC-5 Thomas wrote:
>
> Please coordinate changes with me.
>
>
> I am going to merge this emergency PR without discussion. I'll take full 
> responsibility for doing so.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/929a76d6-7560-4079-9d3b-2d8ec74fe462n%40googlegroups.com.

Re: Leo's jupytext code works!

Well, yes, execution ability will be limited, that's right. VR3 won't know 
about magics, and all the needed libraries will have to be imported in the 
outline. Also graphics that Jupyter would embed won't work.  So execution 
capabilities would be limited, but there will be some outlines that could 
be executed.

On Friday, October 25, 2024 at 10:09:11 PM UTC-4 iamap...@gmail.com wrote:

> A very small addition to VR3's code will allow the notebook to be 
> rendered, and even executed.
>
>
> Hi, Thomas, I believe the rendering is great --- although I can't imagine 
> how this thing works with the @jupytext node.
>
> I think execution may be a bit troublesome, because my usage scenario is 
> that ipynb will be used in different virtual environments, and it will be 
> executed in Leo without corresponding dependencies. If you really need to 
> execute it, you may write some simple scripts, switch to the corresponding 
> environment first, and execute it. But I may still be used to executing it 
> in jupyter.
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/3b663c16-1e37-4062-ad96-34c4bf766d98n%40googlegroups.com.

[tmux/tmux] 40c01c: Allow tabs even on terminals without UTF-8, report...

2024-10-25 Thread &#x27;Thomas Adam' via tmux-git

  Branch: refs/heads/master
  Home:   https://github.com/tmux/tmux
  Commit: 40c01c2d370e637e2ed4dfd247fdecdb84b4ac81
  
https://github.com/tmux/tmux/commit/40c01c2d370e637e2ed4dfd247fdecdb84b4ac81
  Author: nicm 
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
M tty.c

  Log Message:
  ---
  Allow tabs even on terminals without UTF-8, reported by jmc.


  Commit: 895044c52b6bd512bc774af6e5264e85dfe2773f
  
https://github.com/tmux/tmux/commit/895044c52b6bd512bc774af6e5264e85dfe2773f
  Author: Thomas Adam 
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
M tty.c

  Log Message:
  ---
  Merge branch 'obsd-master'


Compare: https://github.com/tmux/tmux/compare/911d768b71dc...895044c52b6b

To unsubscribe from these emails, change your notification settings at 
https://github.com/tmux/tmux/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"tmux-git" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tmux-git+unsubscr...@googlegroups.com.
To view this discussion, visit 
https://groups.google.com/d/msgid/tmux-git/tmux/tmux/push/refs/heads/master/911d76-895044%40github.com.

Re: Head up: PR #4121 (in devel) may cause problems

On Friday, October 25, 2024 at 5:47:47 PM UTC-4 Edward K. Ream wrote:

On Fri, Oct 25, 2024 at 4:33 PM Thomas Passin wrote:

I tested all the layouts in a Linux VM too and they all worked as
intended. All except the one where I had a typo. Are you sure that didn't
happen to you? Which layout had you specified, and what did you get?

I specified the legacy layout and got the vertical thirds. It's all very
strange, but it doesn't matter now.

However, it's not ok with me to use anything other than 'legacy' for the
default layout. People can use myLeoSettings.leo to set their own preferred
default.

When we were posting about what layouts to remove "legacy" came up among
others. I said I wanted to keep the ones aliased to the other names
because someone might be using them. You responded that devel was unstable
anyway and removing the aliases wouldn't matter because people would get
used to the changes. I was under the impression, perhaps wrongly, that you
wanted to keep "quadrant" and get rid of "legacy". I don't know who else
would know what "legacy" is supposed to mean, anyway. Here's the
conversation from your post -

"On Wed, Oct 23, 2024 at 7:19 AM Thomas Passin https://groups.google.com/>> wrote:

** ==> What's the difference b/w 'legacy' & 'quadrant' command ?* ==> I do
not see any & would remove 'quadrant' !*

There isn't a difference and "legacy" has already been removed. It is still
aliased to "quadrant" for the time being in case anyone is using it by that
name. I think that Edward may want to remove "quadrant" as well but that's
not decided for sure.

Thomas, imo there is no reason to retain confusing command names. There is
no downside to doing so. The names are recent, people have no right to
expect stability just yet, and changing them does not constitute a breaking
change to Leo."

--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/leo-editor/f8dc5343-80f0-4053-8f5f-58feb5123eb4n%40googlegroups.com.

[Kea-users] kea-dhcp6-server not running hook scripts

2024-10-25 Thread Justin Thomas via Kea-users

Hi folks,

I’m trying to get the libdhcp_run_script.so library to run a script on DHCPv6 
address assignment and renewal, but I can’t seem to get any signs of life out 
of it. My configuration includes:

"hooks-libraries": [
{
"library": 
"/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_run_script.so",
"parameters": {
"name": "/etc/kea/update-v6.sh",
"sync": false
}
}
],

And my update-v6.sh script looks like:

#!/bin/bash

unknown_handle() {
echo "Unhandled function call ${*}"
exit 123
}


lease6_renew () {
echo "lease6_renew" >> /tmp/ithappened.txt
echo $(env) >> /tmp/ithappened.txt
curl http://23.x.x.x:8383
exit 0
}

lease6_rebind () {
echo "lease6_rebind" >> /tmp/ithappened.txt
echo $(env) >> /tmp/ithappened.txt
curl http://23.x.x.x:8383
exit 0
}

lease6_expire () {
echo "lease6_expire" >> /tmp/ithappened.txt
echo $(env) >> /tmp/ithappened.txt
curl http://23.x.x.x:8383
exit 0
}

lease6_recover () {
echo "lease6_recover" >> /tmp/ithappened.txt
echo $(env) >> /tmp/ithappened.txt
curl http://23.x.x.x:8383
exit 0
}

leases6_committed () {
echo "lease6_committed" >> /tmp/ithappened.txt
echo $(env) >> /tmp/ithappened.txt
curl http://23.x.x.x:8383
exit 0
}

lease6_release () {
echo "lease6_release" >> /tmp/ithappened.txt
echo $(env) >> /tmp/ithappened.txt
curl http://23.x.x.x:8383
exit 0
}

lease6_decline () {
echo "lease6_decline" >> /tmp/ithappened.txt
echo $(env) >> /tmp/ithappened.txt
curl http://23.x.x.x:8383
exit 0
}

case "$1" in
"lease6_renew")
lease6_renew
;;
"lease6_rebind")
lease6_rebind
;;
"lease6_expire")
lease6_expire
;;
"lease6_recover")
lease6_recover
;;
"leases6_committed")
leases6_committed
;;
"lease6_release")
lease6_release
;;
"lease6_decline")
lease6_decline
;;
*)
unknown_handle "${@}"
;;
esac

As you can see, I’m just trying to get some kind of response out of it so that 
I can iterate on it – either as output to a file or even just a curl command 
showing that my server was touched (I was thinking maybe there’s some kind of 
extra file permissions layer that I’m overlooking so I added the curl command 
to see if I could get any kind of response out of it at all).

I can see that the library is loaded:

Oct 25 22:08:13 b1f18944-0de2-4ac0-8a3d-81c5d81c4a0c kea-dhcp6[126798]: INFO  
RUN_SCRIPT_LOAD Run Script hooks library has been loaded
Oct 25 22:08:13 b1f18944-0de2-4ac0-8a3d-81c5d81c4a0c kea-dhcp6[126798]: INFO  
HOOKS_LIBRARY_LOADED hooks library 
/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_run_script.so successfully loaded

…but even when I receive messages like this in the journal:

Oct 25 22:04:11 b1f18944-0de2-4ac0-8a3d-81c5d81c4a0c kea-dhcp6[126689]: INFO  
DHCP6_LEASE_RENEW duid=[00:04:00:00:00:00:00:00:00:00:00:00:ac:1f:6b:49:66:18], 
tid=0x734250: lease for address 2604:2940:f1b0:9e7:0:1:1:0 and iaid=0 has been 
allocated
Oct 25 22:04:12 b1f18944-0de2-4ac0-8a3d-81c5d81c4a0c kea-dhcp6[126689]: INFO  
DHCP6_PD_LEASE_RENEW 
duid=[00:04:00:00:00:00:00:00:00:00:00:00:ac:1f:6b:49:66:18], tid=0x75f834: 
lease for prefix 2604:2940:1::/56 and iaid=0 has been allocated

…I see no activity related to the script execution happening. I can run the 
script manually and it works fine. The permissions are explicitly set to the 
_kea user that is running the server:

root@b1f18944-0de2-4ac0-8a3d-81c5d81c4a0c:/etc/kea# ls -la
total 20
drwxr-xr-x  2 root root 4096 Oct 25 22:14 .
drwxr-xr-x 76 root root 4096 Oct 10 20:38 ..
-rw-r--r--  1 root root 1940 Oct 11 21:47 kea-dhcp4.conf
-rw-r--r--  1 root root 3022 Oct 25 21:51 kea-dhcp6.conf
-rwxr-xr-x  1 _kea root 1641 Oct 25 22:07 update-v6.sh
root@b1f18944-0de2-4ac0-8a3d-81c5d81c4a0c:/etc/kea# ps aux | grep kea-dhcp6
_kea  126798  0.0  0.5  67316 20948 ?Ssl  22:08   0:00 
/usr/sbin/kea-dhcp6 -c /etc/kea/kea-dhcp6.conf
root  126803  0.0  0.4 154112 19760 pts/1S+   22:08   0:00 journalctl 
-xeu kea-dhcp6-server -f
root  126819  0.0  0.0   6652  2236 pts/0S+   22:19   0:00 grep 
kea-dhcp6

I’m at a loss. What am I missing?

-Justin



-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [PATCH v4 00/42] replace strerror

24/10/2024 08:47, huangdengdui:
> On 2024/10/23 23:42, Stephen Hemminger wrote:
> > On Wed, 23 Oct 2024 16:28:10 +0800
> > Dengdui Huang  wrote:
> > 
> >> The function strerror() is insecure in a multi-thread environment.
> >> It is better to use rte_strerror() instead of strerror().
> >> In this patchset, only the libs and drivers are modified.
> > 
> > Even rte_strerror is not completely safe. It depends on the calling
> > thread being a registered lcore.
> 
> As discussed earlier, it is still safe if used from non-DPDK registered 
> threads[1]:
> 
> #define RTE_DEFINE_PER_LCORE(type, name)  \
>   __thread __typeof__(type) per_lcore_##name
> 
> [1]: 
> https://elixir.bootlin.com/dpdk/v23.11-rc3/source/lib/eal/include/rte_per_lcore.h#L37
> 
> > 
> > It would be better to use a coccinelle script to do direct replacement
> > with strerror_r().
> > 
> > Also, rte_strerror is not signal safe.
> 
> Can we use strerror_r() in the signal processing context and replace it with 
> rte_strerror() everywhere else?

It does not make sense to use rte_strerror after libc functions.
Please restrict the use of rte_strerror for error numbers from DPDK functions.

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

2024-10-25 Thread Mark Thomas


On 11/10/2024 01:05, Eric Robinson wrote:

Mark,

Thanks very much for the update. We'll check back in November!


I've just committed the fix. It should be in the next set of releases 
(November).


Mark




-Eric


-Original Message-
From: Mark Thomas 
Sent: Thursday, October 10, 2024 5:30 PM
To: users@tomcat.apache.org
Subject: Re: Database Connection Requests Initiated but Not Sent on the Wire 
(Some, Not All)

Eric,

My apologies. I dropped the ball on this one. I've just re-read the thread to 
remind myself of the details. I'm aiming to get this fixed for the November 
release round.

Mark


On 10/10/2024 10:10, Eric Robinson wrote:

Hi Mark,

Just following up on this. Did you arrive at the long-term solution? This issue 
is still biting us.


-Original Message-
From: Eric Robinson 
Sent: Thursday, May 30, 2024 4:15 PM
To: Tomcat Users List 
Subject: RE: Database Connection Requests Initiated but Not Sent on
the Wire (Some, Not All)

Hi Mark,


-Original Message-----
From: Mark Thomas 
Sent: Thursday, May 30, 2024 9:30 AM
To: users@tomcat.apache.org
Subject: Re: Database Connection Requests Initiated but Not Sent on
the Wire (Some, Not All)

OK.

This is an interim binary patch for 9.0.80 only.

The purpose is to:
- confirm the proposed change fixes the problem
- provide you with a workaround in the short term

This is the binary patch:

https://people.apache.org/~markt/dev/classloader-not-found-cache-9.0.
8
0-
v1.zip

Extract the contents into $CATALINA_HOME/lib

You should end up with:

$CATALINA_HOME/lib/org/apache/...



I'll get on this right away.


Usual caveats apply. This is not an official release. Use it at your
own risk. Don't blame either me or the ASF it is results in alien
invasion, a tax bill, the server catching fire or anything else unexpected 
and/or unwanted.



Okay, but if we're invaded by alien tax collectors riding flaming servers, THEN 
I'm coming after you.


Longer term, I'm not sure this is exactly how I want to fix it in
Tomcat. I am convinced of the need to cache classes that don't exist
but exactly where / how to do that and what degree of control the user should 
have is very much TBD.

I suspect this will be a topic of discussion at Community Over Code
at Bratislava next week.

I am expecting that any fix won't be in the June release round but
should be in the July release round.

Let us know how you get on and good luck.



Will do!



Mark


On 30/05/2024 10:16, Mark Thomas wrote:

On 29/05/2024 17:03, Eric Robinson wrote:




One of the webapps is related to voice reminder messages that go
out to people. The reminders go out sometime after 9 am, which
tracks with the slowdowns.


Ack.

Something to try while I work on a patch is setting
archiveIndexStrategy="bloom" on the resources.

You'd configure that in META-INF/context.xml something like this:


  

Mark


- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.
Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Disclaimer : This email and any files transmitted

Re: [PATCH] MAINTAINERS: add maintainer for next-net-intel tree

24/10/2024 18:41, Stephen Hemminger:
> On Thu, 24 Oct 2024 15:51:22 +0100
> Bruce Richardson  wrote:
> 
> > For last two releases, I have been committer for the next-net-intel
> > tree, so update the details in MAINTAINERS file to reflect that fact.
> > 
> > Signed-off-by: Bruce Richardson 
> > ---
> >  MAINTAINERS | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index f8eecb4527..ab64230920 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -37,6 +37,7 @@ M: Ajit Khaparde 
> >  T: git://dpdk.org/next/dpdk-next-net-brcm
> >  
> >  Next-net-intel Tree
> > +M: Bruce Richardson 
> >  T: git://dpdk.org/next/dpdk-next-net-intel
> >  
> >  Next-net-mrvl Tree
> 
> Acked-by: Stephen Hemminger 

Applied, thanks.

Re: [PATCH] MAINTAINERS: add maintainers for Intel NIC drivers

24/10/2024 18:42, Stephen Hemminger:
> On Thu, 24 Oct 2024 16:05:29 +0100
> Bruce Richardson  wrote:
> 
> > The ixgbe, i40e, iavf and ice NIC drivers are all actively maintained
> > and receiving updates. Add official maintainer names for these drivers
> > in the MAINTAINERS file.
> > 
> > Signed-off-by: Bruce Richardson 
> 
> Acked-by: Stephen Hemminger 

Applied, thanks.

Re: [Qgis-user] QGIS-User Digest, Vol 224, Issue 29

2024-10-25 Thread Thomas Struller via QGIS-User

Hallo Olaf,

did you check wether your shape-file has defined coordinate system? you find it 
under properties / Eigenschaften



--

Freundliche Grüße

Thomas Struller
Diplom Geologe BDG, V18
akademischer Geoinformatiker
Sachverständiger nach BBodSchG §18
SG1 historische Recherche
SG2 Pfad Boden-Grundwasser
privater Sachverständiger der Wasserwirtschaft


T  +49 911 12076-111
M +49 170 3320494
thomas.strul...@lga-geo.de<mailto:thomas.strul...@lga-geo.de>

LGA Institut für Umweltgeologie und Altlasten GmbH
Christian-Hessel-Straße 1 | 90427 Nürnberg
Geschäftsführung: Carlo Schillinger | Dr. Jürgen Kisskalt
Gesellschaftssitz: Nürnberg | Registergericht Nürnberg HRB 18895
i...@lga-geo.de<mailto:i...@lga-geo.de> | LGA-geo.de<https://www.lga-geo.de/> | 
Datenschutz<https://www.lga-geo.de/datenschutz/>

Wir sind auf dem Weg zu einem papierfreien Büro.
Berichte, Rechnungen und weitere Dokumente empfangen und
versenden wir bevorzugt elektronisch per E-Mail.

Am Freitag, dem 25.10.2024 um 12:00 -0700 schrieb 
qgis-user-requ...@lists.osgeo.org:
Send QGIS-User mailing list submissions to
qgis-user@lists.osgeo.org<mailto:qgis-user@lists.osgeo.org>

To subscribe or unsubscribe via the World Wide Web, visit
https://eu-central-1.protection.sophos.com?d=osgeo.org&u=aHR0cHM6Ly9saXN0cy5vc2dlby5vcmcvbWFpbG1hbi9saXN0aW5mby9xZ2lzLXVzZXI=&i=NWJmNDNkYTViNDcwM2ExMzMzYzBjODA3&t=ZUNtT2tIdmZxUFJBNjl6em5KanVjN3dOQ0IyelRWTGJUSkd1aW83amdGbz0=&h=28b881a5762c4c929e5d81bce5e6aedb&s=AVNPUEhUT0NFTkNSWVBUSVaRyLBYg7FG535Y34Sqfpep5ui1l8QV4UOfwirlejwhGbIo2AGGJPminqPLF4GdjflWceToB1hySPgHM0vzeEPE
or, via email, send a message with subject or body 'help' to
qgis-user-requ...@lists.osgeo.org<mailto:qgis-user-requ...@lists.osgeo.org>

You can reach the person managing the list at
qgis-user-ow...@lists.osgeo.org<mailto:qgis-user-ow...@lists.osgeo.org>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of QGIS-User digest..."


Today's Topics:

   1. QGIS-Layer l?sst sich nicht bearbeiten 
(olaf.schw...@gmail.com<mailto:olaf.schw...@gmail.com>)
   2. Antw:  QGIS-Layer l?sst sich nicht bearbeiten (..bis
  einschlie?lich 28.10.24 abwesend) (Michael Rose)


--

Message: 1
Date: Fri, 25 Oct 2024 15:39:19 +0200
From: olaf.schw...@gmail.com<mailto:olaf.schw...@gmail.com>
To: mailto:qgis-user@lists.osgeo.org>>
Subject: [Qgis-user] QGIS-Layer l?sst sich nicht bearbeiten
Message-ID: 
<007801db26e3$4baef330$e30cd990$@gmail.com<mailto:007801db26e3$4baef330$e30cd990$@gmail.com>>
Content-Type: text/plain; charset="iso-8859-1"

Hallo QGIS-Community,



Woran kann es liegen, dass ich einen Layer nicht bearbeiten kann?

Er lag mir erst als Shape-Datei vor, ich habe ihn dann in ein Geopackage
umgewandelt.



Was muss ich machen, damit ich den Layer bearbeiten bzw. ?ndern kann?



Mit freundlichen Gr??en,



Olaf Schwenk

mobil: +49 173 8099007



-- next part --
An HTML attachment was scrubbed...
URL: 
<https://eu-central-1.protection.sophos.com?d=osgeo.org&u=aHR0cDovL2xpc3RzLm9zZ2VvLm9yZy9waXBlcm1haWwvcWdpcy11c2VyL2F0dGFjaG1lbnRzLzIwMjQxMDI1LzkxNjI2YjMwL2F0dGFjaG1lbnQtMDAwMS5odG0=&i=NWJmNDNkYTViNDcwM2ExMzMzYzBjODA3&t=M0pzd0t0RGNTMW9lWXo0T2VQTzdPMjZyU0pycjdUdmFySUdOdWpveFVDVT0=&h=28b881a5762c4c929e5d81bce5e6aedb&s=AVNPUEhUT0NFTkNSWVBUSVaRyLBYg7FG535Y34Sqfpep5ui1l8QV4UOfwirlejwhGbIo2AGGJPminqPLF4GdjflWceToB1hySPgHM0vzeEPE>

--

Message: 2
Date: Fri, 25 Oct 2024 15:40:15 +0200
From: "Michael Rose" mailto:m.r...@en-kreis.de>>
To: mailto:olaf.schw...@gmail.com>>, "Olaf Schwenk via 
QGIS-User"
mailto:qgis-user@lists.osgeo.org>>
Subject: [Qgis-user] Antw:  QGIS-Layer l?sst sich nicht bearbeiten
(..bis einschlie?lich 28.10.24 abwesend)
Message-ID: 
<671b9fbf025800120...@gw.erk-intern.nov<mailto:671b9fbf025800120...@gw.erk-intern.nov>>
Content-Type: text/plain; charset=ISO-8859-1

Sehr geehrte Damen und Herren,

ich bin ab dem 29. Oktober erst wieder erreichbar.
Ihre Email wird nicht weitergeleitet.

In dringenden F?llen wenden Sie sich bitte an an das GIS-Team (02336/93-2483).

Mit freundlichen Gr??en
Michael Rose


--

Subject: Digest Footer

___
QGIS-User mailing list
QGIS-User@lists.osgeo.org<mailto:QGIS-User@lists.osgeo.org>
List info: 
https://eu-central-1.protection.sophos.com?d=osgeo.org&u=aHR0cHM6Ly9saXN0cy5vc2dlby5vcmcvbWFpbG1hbi9saXN0aW5mby9xZ2lzLXVzZXI=&i=NWJmNDNkYTViNDcwM2ExMzMzYzBjODA3&t=ZUNtT2tIdmZxUFJBNjl6em5KanVjN3dOQ0IyelRWTGJUSkd1aW83amdGbz0=&h=28b881a5762c4c929e5d81bce5e6aedb&s=AVNPUEhUT0NFTkNSWVBUSVaRyLBYg7FG535Y34Sqfpep5ui1l8QV4UOf

Re: Head up: PR #4121 (in devel) may cause problems

I just went through them all in turn and Leo started up with the right 
layout each time.

I tested by putting the setting node into the setting tree in my 
workbook.leo outline, changing the specified layout, and starting a new 
session of Leo that opens just the workbook.

I am aware of a problem I've had from time to time where VR (not VR3) 
doesn't show up.  The log pane shows the message that the VR pane has been 
turned on or off but VR isn't actually visible.  As you said, there's a 
workaround so I thought we could tackle it after getting the layout 
machinery into devel.

If VR doesn't show itself one might get fooled into thinking that the wrong 
layout had been loaded - depending on the layout, of course.

On Friday, October 25, 2024 at 3:04:24 PM UTC-4 Thomas Passin wrote:

> Please coordinate changes with me.
>
> On Friday, October 25, 2024 at 2:59:42 PM UTC-4 Edward K. Ream wrote:
>
>> I encountered strange behavior after merging #4121 into devel. *Leo 
>> opened with a different layout than the one my settings specified.* The 
>> workaround was to execute the 'layout-quadrant' command.
>>
>> Imo, the "devel" branch is unacceptable. I am working on an urgent fix, 
>> PR #4126 <https://github.com/leo-editor/leo-editor/pull/4126>. 
>>
>> I plan to complete and pull the PR later today. My apologies for this 
>> mess.
>>
>> Edward
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/146f7c44-709d-4440-9047-1f350cb9729fn%40googlegroups.com.

Re: Head up: PR #4121 (in devel) may cause problems

What layout is in your settings?

On Friday, October 25, 2024 at 2:59:42 PM UTC-4 Edward K. Ream wrote:

> I encountered strange behavior after merging #4121 into devel. *Leo 
> opened with a different layout than the one my settings specified.* The 
> workaround was to execute the 'layout-quadrant' command.
>
> Imo, the "devel" branch is unacceptable. I am working on an urgent fix, PR 
> #4126 . 
>
> I plan to complete and pull the PR later today. My apologies for this mess.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/6f6e55ab-0abb-4ff5-9290-895ac40a481dn%40googlegroups.com.

Re: Head up: PR #4121 (in devel) may cause problems

Please coordinate changes with me.

On Friday, October 25, 2024 at 2:59:42 PM UTC-4 Edward K. Ream wrote:

> I encountered strange behavior after merging #4121 into devel. *Leo 
> opened with a different layout than the one my settings specified.* The 
> workaround was to execute the 'layout-quadrant' command.
>
> Imo, the "devel" branch is unacceptable. I am working on an urgent fix, PR 
> #4126 . 
>
> I plan to complete and pull the PR later today. My apologies for this mess.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/leo-editor/7b34835b-583a-45dd-a65e-28a207ed1b23n%40googlegroups.com.

Re: [Histonet] Goverment regulations for reusing Biological transport bags

2024-10-25 Thread Thomas Podawiltz via Histonet

I believe Dan the Safety Man has covered this issue in the past. 


Sent from Yahoo Mail for iPad


On Friday, October 25, 2024, 1:25 PM, Eileen Akemi Allison via Histonet 
 wrote:

Happy Friday Histo Land:

I am proposing this question for a friend who is a new supervisor in a fairly 
active pathology lab.  She is not on Histonet.

Do any of you know of any OHSA or any other regulatory agencies regulations 
regarding re-using Biological Transport Bags which have been used for 
transporting tissue specimen containers to the pathology lab?  I have never 
re-used them in other labs I have worked at.  We have disposed of them in our 
Biological Waste receptacle.  I could only find information regarding 
blood-born pathogens in the OHSA guidelines.  Any references would be greatly 
appreciated.  Thank you in advance for your assistance. 

Best regards,

Akemi Allison-Tacha BS, HT/HTL (ASCP)
Pathology Laboratory Manager at Golden State Dermatopathology
370 N Wiget Lane, Suite 250, Walnut Creek. CA 94598
(925) 278-7592 Ext: 10079
Mobil:: (408) 335-9994
W: Email: aalli...@gsdermca.com 
Website: www.goldenstatedermatology.com 
___
Histonet mailing list
Histonet@lists.utsouthwestern.edu
http://lists.utsouthwestern.edu/mailman/listinfo/histonet



___
Histonet mailing list
Histonet@lists.utsouthwestern.edu
http://lists.utsouthwestern.edu/mailman/listinfo/histonet

[kommit] [Bug 495351] New: kommitdiff

2024-10-25 Thread Thomas Braun

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

Bug ID: 495351
   Summary: kommitdiff
Classification: Applications
   Product: kommit
   Version: unspecified
  Platform: Arch Linux
OS: Linux
Status: REPORTED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: hamed.mas...@gmail.com
  Reporter: groth...@gmail.com
CC: mon...@kde.org
  Target Milestone: ---

Application: kommit (1.6.0)

ApplicationNotResponding [ANR]: false
Qt Version: 6.8.0
Frameworks Version: 6.7.0
Operating System: Linux 6.11.5-arch1-1 x86_64
Windowing System: Wayland
Distribution: EndeavourOS
DrKonqi: 6.2.2 [CoredumpBackend]

-- Information about the crash:
Simple start of kommitdiff, no special actions needed to cause this crash. 
Only kommitdiff crashes, kommit and kommitmerge are running.

The crash can be reproduced every time.

-- Backtrace:
Application: Kommit (kommit), signal: Segmentation fault
Content of s_kcrashErrorMessage: std::unique_ptr = {get() = }

warning: Can't open file anon_inode:i915.gem which was expanded to
anon_inode:i915.gem during file-backed mapping note processing
[New LWP 21825]
[New LWP 21826]
[New LWP 21829]
[New LWP 21830]
[New LWP 21827]
[New LWP 21828]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `kommit diff'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __pthread_kill_implementation (threadid=,
signo=signo@entry=11, no_tid=no_tid@entry=0) at pthread_kill.c:44
44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO
(ret) : 0;
[Current thread is 1 (Thread 0x71c0c30eba00 (LWP 21825))]

Cannot QML trace cores :(
/usr/share/drkonqi/gdb/python/gdb_preamble/preamble.py:516: DeprecationWarning:
datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in
a future version. Use timezone-aware objects to represent datetimes in UTC:
datetime.datetime.fromtimestamp(timestamp, datetime.UTC).
  boot_time =
datetime.utcfromtimestamp(psutil.boot_time()).strftime('%Y-%m-%dT%H:%M:%S')
/usr/share/drkonqi/gdb/python/gdb_preamble/preamble.py:533: DeprecationWarning:
datetime.datetime.utcnow() is deprecated and scheduled for removal in a future
version. Use timezone-aware objects to represent datetimes in UTC:
datetime.datetime.now(datetime.UTC).
  'timestamp': datetime.utcnow().isoformat(),
[Current thread is 1 (Thread 0x71c0c30eba00 (LWP 21825))]

Thread 6 (Thread 0x71c0bbe006c0 (LWP 21828)):
#0  0x71c0c991a63d in __GI___poll (fds=fds@entry=0x71c0bbdffb20,
nfds=nfds@entry=2, timeout=timeout@entry=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
#1  0x71c0c396e417 in poll (__fds=0x71c0bbdffb20, __nfds=2, __timeout=-1)
at /usr/include/bits/poll2.h:44
#2  QtWaylandClient::EventThread::run (this=0x5e84d4696ef0) at
/usr/src/debug/qt6-wayland/qtwayland/src/client/qwaylanddisplay.cpp:182
#3  0x71c0c9cd840f in operator() (__closure=) at
/usr/src/debug/qt6-base/qtbase/src/corelib/thread/qthread_unix.cpp:335
#4  (anonymous
namespace)::terminate_on_exception >
(t=...) at
/usr/src/debug/qt6-base/qtbase/src/corelib/thread/qthread_unix.cpp:263
#5  QThreadPrivate::start (arg=0x5e84d4696ef0) at
/usr/src/debug/qt6-base/qtbase/src/corelib/thread/qthread_unix.cpp:294
#6  0x71c0c98a339d in start_thread (arg=) at
pthread_create.c:447
#7  0x71c0c992849c in __GI___clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

Thread 5 (Thread 0x71c0c0e006c0 (LWP 21827)):
#0  0x71c0c989fa19 in __futex_abstimed_wait_common64 (private=0,
futex_word=0x5e84d466a7f0, expected=0, op=393, abstime=0x0, cancel=true) at
futex-internal.c:57
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x5e84d466a7f0,
expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2  0x71c0c989fa9f in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x5e84d466a7f0, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at
futex-internal.c:139
#3  0x71c0c98a2479 in __pthread_cond_wait_common (cond=0x5e84d466a7c8,
mutex=, clockid=0, abstime=0x0) at pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x5e84d466a7c8, mutex=) at
pthread_cond_wait.c:618
#5  0x71c0c9cdd030 in QWaitConditionPrivate::wait (this=0x5e84d466a7a0,
deadline=...) at
/usr/src/debug/qt6-base/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:102
#6  QWaitCondition::wait (this=this@entry=0x5e84d470ef10,
mutex=mutex@entry=0x5e84d470ef08, deadline=...) at
/usr/src/debug/qt6-base/qtbase/src/corelib/thread/qwaitcondition_unix.cpp:180
#7  0x71c0c396e3af in QtWaylandClient::EventThread::waitForReading
(this=0x5e84d470eed0) at
/usr/src/debug/qt6-wayland/qtwayland/src/client/qwaylanddisplay.cpp:216
#8

[tmux/tmux] fdbc6c: Flag tabs if possible in the grid cell so they can...

2024-10-25 Thread &#x27;Thomas Adam' via tmux-git

  Branch: refs/heads/master
  Home:   https://github.com/tmux/tmux
  Commit: fdbc6cdea543695bb10622d1a483507639f52ad9
  
https://github.com/tmux/tmux/commit/fdbc6cdea543695bb10622d1a483507639f52ad9
  Author: nicm 
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
M grid-reader.c
M grid.c
M input.c
M screen-write.c
M tmux.h
M window-copy.c

  Log Message:
  ---
  Flag tabs if possible in the grid cell so they can be preserved on
copying and capture-pane. From Alexander Arch in GitHub issue 4201.


  Commit: eaec0a48f4f07060f4bdfdd19fe8cd3fe5818fe7
  
https://github.com/tmux/tmux/commit/eaec0a48f4f07060f4bdfdd19fe8cd3fe5818fe7
  Author: nicm 
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
M format.c
M window-copy.c

  Log Message:
  ---
  Do not stop stop at first padding in format_grid_line and handle tabs.


  Commit: 487b0ee124363f838bfd5dcc1dcccd4db22f414a
  
https://github.com/tmux/tmux/commit/487b0ee124363f838bfd5dcc1dcccd4db22f414a
  Author: nicm 
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
M window-copy.c

  Log Message:
  ---
  Do not attempt to search for zero length strings, from Alexander Arch in
GitHub issue 4209.


  Commit: 71a503e40c48bf36c66f9723faa0c9aa0a828363
  
https://github.com/tmux/tmux/commit/71a503e40c48bf36c66f9723faa0c9aa0a828363
  Author: nicm 
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
M status.c
M tmux.h

  Log Message:
  ---
  Allow control characters to be entered at the command prompt prefixed
with with C-v, from  Alexander Arch in GitHub issue 4206.


  Commit: 911d768b71dc22eb03898df6db649df13c41b020
  
https://github.com/tmux/tmux/commit/911d768b71dc22eb03898df6db649df13c41b020
  Author: Thomas Adam 
  Date:   2024-10-25 (Fri, 25 Oct 2024)

  Changed paths:
M format.c
M grid-reader.c
M grid.c
M input.c
M screen-write.c
M status.c
M tmux.h
M window-copy.c

  Log Message:
  ---
  Merge branch 'obsd-master'


Compare: https://github.com/tmux/tmux/compare/9623ec3ee45d...911d768b71dc

To unsubscribe from these emails, change your notification settings at 
https://github.com/tmux/tmux/settings/notifications

-- 
You received this message because you are subscribed to the Google Groups 
"tmux-git" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tmux-git+unsubscr...@googlegroups.com.
To view this discussion, visit 
https://groups.google.com/d/msgid/tmux-git/tmux/tmux/push/refs/heads/master/9623ec-911d76%40github.com.

[gcc r15-4677] Fortran: Fix ICE with structure constructor in data statement [PR79685]

2024-10-25 Thread Paul Thomas via Gcc-cvs

https://gcc.gnu.org/g:6cb1da72cac166bd3b005c0430557b68b9761da5

commit r15-4677-g6cb1da72cac166bd3b005c0430557b68b9761da5
Author: Paul Thomas 
Date:   Fri Oct 25 17:59:03 2024 +0100

Fortran: Fix ICE with structure constructor in data statement [PR79685]

2024-10-25  Paul Thomas  

gcc/fortran
PR fortran/79685
* decl.cc (match_data_constant): Find the symtree instead of
the symbol so the use renamed symbols are found. Pass this and
the derived type to gfc_match_structure_constructor.
* match.h: Update prototype of gfc_match_structure_contructor.
* primary.cc (gfc_match_structure_constructor): Remove call to
gfc_get_ha_sym_tree and use caller supplied symtree instead.

gcc/testsuite/
PR fortran/79685
* gfortran.dg/use_rename_13.f90: New test.

Diff:
---
 gcc/fortran/decl.cc |  7 --
 gcc/fortran/match.h |  2 +-
 gcc/fortran/primary.cc  |  8 +++
 gcc/testsuite/gfortran.dg/use_rename_13.f90 | 37 +
 4 files changed, 46 insertions(+), 8 deletions(-)

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 499a8462629e..000c8dcf34ed 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -377,6 +377,7 @@ match_data_constant (gfc_expr **result)
   gfc_expr *expr;
   match m;
   locus old_loc;
+  gfc_symtree *symtree;
 
   m = gfc_match_literal_constant (&expr, 1);
   if (m == MATCH_YES)
@@ -437,9 +438,11 @@ match_data_constant (gfc_expr **result)
   if (m != MATCH_YES)
 return m;
 
-  if (gfc_find_symbol (name, NULL, 1, &sym))
+  if (gfc_find_sym_tree (name, NULL, 1, &symtree))
 return MATCH_ERROR;
 
+  sym = symtree->n.sym;
+
   if (sym && sym->attr.generic)
 dt_sym = gfc_find_dt_in_generic (sym);
 
@@ -453,7 +456,7 @@ match_data_constant (gfc_expr **result)
   return MATCH_ERROR;
 }
   else if (dt_sym && gfc_fl_struct (dt_sym->attr.flavor))
-return gfc_match_structure_constructor (dt_sym, result);
+return gfc_match_structure_constructor (dt_sym, symtree, result);
 
   /* Check to see if the value is an initialization array expression.  */
   if (sym->value->expr_type == EXPR_ARRAY)
diff --git a/gcc/fortran/match.h b/gcc/fortran/match.h
index b2158e12a92f..13972bfe3e10 100644
--- a/gcc/fortran/match.h
+++ b/gcc/fortran/match.h
@@ -303,7 +303,7 @@ match gfc_match_bind_c_stmt (void);
 match gfc_match_bind_c (gfc_symbol *, bool);
 
 /* primary.cc.  */
-match gfc_match_structure_constructor (gfc_symbol *, gfc_expr **);
+match gfc_match_structure_constructor (gfc_symbol *, gfc_symtree *, gfc_expr 
**);
 match gfc_match_variable (gfc_expr **, int);
 match gfc_match_equiv_variable (gfc_expr **);
 match gfc_match_actual_arglist (int, gfc_actual_arglist **, bool = false);
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index f3f659cf8dfe..0f258edd1294 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -3648,18 +3648,16 @@ gfc_convert_to_structure_constructor (gfc_expr *e, 
gfc_symbol *sym, gfc_expr **c
 
 
 match
-gfc_match_structure_constructor (gfc_symbol *sym, gfc_expr **result)
+gfc_match_structure_constructor (gfc_symbol *sym, gfc_symtree *symtree,
+gfc_expr **result)
 {
   match m;
   gfc_expr *e;
-  gfc_symtree *symtree;
   bool t = true;
 
-  gfc_get_ha_sym_tree (sym->name, &symtree);
-
   e = gfc_get_expr ();
-  e->symtree = symtree;
   e->expr_type = EXPR_FUNCTION;
+  e->symtree = symtree;
   e->where = gfc_current_locus;
 
   gcc_assert (gfc_fl_struct (sym->attr.flavor)
diff --git a/gcc/testsuite/gfortran.dg/use_rename_13.f90 
b/gcc/testsuite/gfortran.dg/use_rename_13.f90
new file mode 100644
index ..97f26f42f762
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/use_rename_13.f90
@@ -0,0 +1,37 @@
+! { dg-do compile }
+!
+! Test the fix for pr79685, which failed as in the comments below.
+!
+! Contributed by Juergen Reuter  
+!
+module omega_color
+  implicit none
+
+  type omega_color_factor
+ integer :: i
+  end type
+
+  type(omega_color_factor), parameter :: op = omega_color_factor (199)
+
+end module
+
+module foo
+  use omega_color, ocf => omega_color_factor, ocfp => op
+  implicit none
+
+  type(ocf) :: table_color_factors1 = ocf(42)
+  type(ocf) :: table_color_factors2
+  type(ocf) :: table_color_factors3 (2)
+  type(ocf) :: table_color_factors4
+  data table_color_factors2 / ocf(99) /! This failed in 
gfc_match_structure_constructor.
+  data table_color_factors3 / ocf(1), ocf(2) / ! ditto.
+  data table_color_factors4 / ocfp /
+end module
+
+  use foo
+  if (table_color_factors1%i .ne. 42) stop 1
+  if (table_color_factors2%i .ne. 99) stop 2
+  if (any (table_color_factors3%i .ne. [1,2])) stop 3
+  if (table_color_factors4%i .ne. 199) stop 4
+end
+

Re: RFR: 8319875: Add macOS implementation for jcmd System.map

2024-10-25 Thread Thomas Stuefe

On Wed, 11 Sep 2024 18:22:00 GMT, Simon Tooke  wrote:

> This is a port of #16301  to macOS.
> 
> System.map and System.dump_map are implemented using the macOS API and 
> provide roughly the same information in the same format. Most of the heavy 
> lifting was implemented by @tstuefe in 
> https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS 
> implementation and enables the common code for macOS 64 bit.
> 
> The System.map tests are also reworked to be cleaner for the three 
> implementations.
> 
> [Sample output](https://github.com/user-attachments/files/17517412/sample.txt)

Nice work, thank you. Small nits inside. I have no time to test this 
extensively, but if the tests run through, it should be fine.

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 120:

> 118: 
> 119:   static const char* tagToStr(uint32_t user_tag) {
> 120: switch (user_tag) {

You could reduce the code and remove duplications with an [x 
macro](https://en.wikipedia.org/wiki/X_macro) if you wanted.

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 360:

> 358:   break;
> 359: } else if (retval < (int)sizeof(region_info)) {
> 360:   fatal("proc_pidinfo() returned %d", retval);

I would make this an assert, and return without printing anything in release.

-

PR Review: https://git.openjdk.org/jdk/pull/20953#pullrequestreview-2395601473
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1816880506
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1816894551

Re: [PATCH] doc: enhanced build instructions on Windows