On 2025-02-03 15:52, Samuel Thibault wrote:
Better not ask Debian maintainers. In the end it has to land to
upstream, so better just take it there.
Got it! :)
--
Yuqian Yang
Yuqian Yang, le lun. 03 févr. 2025 15:39:32 +0800, a ecrit:
> > Ok I will send a patch to vim to exclude has('bsd') using
> > defined(__GNU__), do you think adding a has() (maybe has('hurd')?) for
> > Hurd
> > should also be submitted with the patch?
>
> I think that needs to be discussed with vim
Zhaoming Luo, le lun. 03 févr. 2025 15:12:07 +0800, a ecrit:
> On Mon, Feb 03, 2025 at 07:32:42AM +0100, Samuel Thibault wrote:
> > Hello,
> >
> > Zhaoming Luo, le lun. 03 févr. 2025 12:58:13 +0800, a ecrit:
> > > So the story in short is that vim thinks it is compiled for bsd kernel.
> > > You ca
Zhaoming Luo, le lun. 03 févr. 2025 14:44:33 +0800, a ecrit:
> On Mon, Feb 03, 2025 at 07:32:42AM +0100, Samuel Thibault wrote:
> > Hello,
> >
> > Zhaoming Luo, le lun. 03 févr. 2025 12:58:13 +0800, a ecrit:
> > > So the story in short is that vim thinks it is compiled for bsd kernel.
> > > You ca
Ok I will send a patch to vim to exclude has('bsd') using
defined(__GNU__), do you think adding a has() (maybe has('hurd')?) for
Hurd
should also be submitted with the patch?
I think that needs to be discussed with vim maintainer.
Debian has its own package patch system. If upstream does not
Hello,
Zhaoming Luo, le lun. 03 févr. 2025 12:22:11 +0800, a ecrit:
> ```
> Run 1, 13:51:24 - 13:51:24 in 0.02 seconds:
> command line..script
> /<>/src/vim-gtk3/testdir/runtest.vim[617]..function
> RunTheTest[57]..Test_keep_pty_open line 6: Expected range 200 - 1000, but got
> 20
So it b
Feb 3, 2025 14:39:39 Zhaoming Luo :
Ok, maybe I should try to be more patient :-). Thanks anyway.
Actually you don't have to unless it's worth it. I just used to work by
finding/fixing codes on large code base, so I might be a little quicker.
And I am also curious about why BSD is defined her
On Mon, Feb 03, 2025 at 07:32:42AM +0100, Samuel Thibault wrote:
> Hello,
>
> Zhaoming Luo, le lun. 03 févr. 2025 12:58:13 +0800, a ecrit:
> > So the story in short is that vim thinks it is compiled for bsd kernel.
> > You can reproduce the issue by running `:echo has('bsd')` in vim on
> > Hurd. T
On Mon, Feb 03, 2025 at 07:39:25AM +0100, Samuel Thibault wrote:
> Yuqian Yang, le lun. 03 févr. 2025 14:37:16 +0800, a ecrit:
> > On 2025-02-03 14:24, Zhaoming Luo wrote:
> > > Cool how to you find it?
> >
> > Not a very wise way. Track codes, search with grep or other tools.
> >
> > gcc preproc
On Mon, Feb 03, 2025 at 07:32:42AM +0100, Samuel Thibault wrote:
> Hello,
>
> Zhaoming Luo, le lun. 03 févr. 2025 12:58:13 +0800, a ecrit:
> > So the story in short is that vim thinks it is compiled for bsd kernel.
> > You can reproduce the issue by running `:echo has('bsd')` in vim on
> > Hurd. T
Samuel Thibault, le lun. 03 févr. 2025 07:39:25 +0100, a ecrit:
> Yuqian Yang, le lun. 03 févr. 2025 14:37:16 +0800, a ecrit:
> > On 2025-02-03 14:24, Zhaoming Luo wrote:
> > > Cool how to you find it?
> >
> > Not a very wise way. Track codes, search with grep or other tools.
> >
> > gcc preproce
Yuqian Yang, le lun. 03 févr. 2025 14:37:16 +0800, a ecrit:
> On 2025-02-03 14:24, Zhaoming Luo wrote:
> > Cool how to you find it?
>
> Not a very wise way. Track codes, search with grep or other tools.
>
> gcc preprocessor can do this with gcc -E. But it does not work for
> system headers.
You
On Mon, Feb 03, 2025 at 02:37:16PM +0800, Yuqian Yang wrote:
> On 2025-02-03 14:24, Zhaoming Luo wrote:
> > Cool how to you find it?
>
> Not a very wise way. Track codes, search with grep or other tools.
Ok, maybe I should try to be more patient :-). Thanks anyway.
>
> gcc preprocessor can do th
On 2025-02-03 14:24, Zhaoming Luo wrote:
Cool how to you find it?
Not a very wise way. Track codes, search with grep or other tools.
gcc preprocessor can do this with gcc -E. But it does not work for
system headers.
--
Yuqian Yang
Hello,
Zhaoming Luo, le lun. 03 févr. 2025 12:58:13 +0800, a ecrit:
> So the story in short is that vim thinks it is compiled for bsd kernel.
> You can reproduce the issue by running `:echo has('bsd')` in vim on
> Hurd. The implementation of `has()` is in [2]. The `has('bsd')` is
> covered by `#if
On Mon, Feb 03, 2025 at 02:14:14PM +0800, Yuqian Yang wrote:
> On 2025-02-03 12:58, Zhaoming Luo wrote:
>
> > ... I haven't found a
> > practical method to track where the BSD macro is defined during
> > compilation.
>
> It is defined in `/usr/include/x86_64-gnu/bits/param.h'.
>
> The including
On 2025-02-03 12:58, Zhaoming Luo wrote:
... I haven't found a
practical method to track where the BSD macro is defined during
compilation.
It is defined in `/usr/include/x86_64-gnu/bits/param.h'.
The including chain is,
vim/src/evalfunc.c
vim/src/os_unix.h
/usr/include/x86_64-gnu/sys/param.
On 2025-02-03 12:37, Nathan Dehnel wrote:
Rust is not "memory safe" in a way that prevents memory leaks.
Nice point. Thanks for explaining it. I think I have misunderstood
the relationship of these two concepts, "memory safe" and "memory leak".
It reminds me of a joke that C++ is such a "weak"
Hi,
This test failed is quite interesting. (source code [0])
Error log after running "make test_functions":
```
...
1 FAILED:
Found errors in Test_platform_name():
command line..script /home/1speaker/vim/src/testdir/runtest.vim[617]..function
RunTheTest[57]..Test_platform_name line 18: Expected
Rust is not "memory safe" in a way that prevents memory leaks.
https://youtu.be/OcQgBeEyxyc
Hi,
I hope this is the right place to post the discussion like this, as I
can confirm the test failed reason is not related to vim and it's quite
hard for me to track the issue alone. I think some discussion will be
helpful to solve the issue.
In the build log[0]:
```
>From test_channel.vim:
Fou
This port extends the existing i686 port to support x86_64 by reusing
existing code whenever it makes sense.
* gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and
position of amd64 registers in the different Hurd structs.
The signal code is very similar to i686, except the trampoli
On Sun, Feb 02, 2025 at 12:13:17PM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le dim. 02 févr. 2025 19:09:45 +0800, a ecrit:
> > On Sun, Feb 02, 2025 at 12:00:17PM +0100, Samuel Thibault wrote:
> > > Zhaoming Luo, le dim. 02 févr. 2025 18:55:49 +0800, a ecrit:
> > > > ```
> > > > Thread 2 hit Br
Zhaoming Luo, le dim. 02 févr. 2025 19:09:45 +0800, a ecrit:
> On Sun, Feb 02, 2025 at 12:00:17PM +0100, Samuel Thibault wrote:
> > Zhaoming Luo, le dim. 02 févr. 2025 18:55:49 +0800, a ecrit:
> > > ```
> > > Thread 2 hit Breakpoint 1, _hurd_select (nfds=7, pollfds=0x0,
> > > readfds=0x103cc20, wr
On Sun, Feb 02, 2025 at 12:00:17PM +0100, Samuel Thibault wrote:
> Zhaoming Luo, le dim. 02 févr. 2025 18:55:49 +0800, a ecrit:
> > ```
> > Thread 2 hit Breakpoint 1, _hurd_select (nfds=7, pollfds=0x0,
> > readfds=0x103cc20, writefds=0x103cc40, exceptfds=0x103cc60,
> > timeout=0x103cba4, sigma
Zhaoming Luo, le dim. 02 févr. 2025 18:55:49 +0800, a ecrit:
> ```
> Thread 2 hit Breakpoint 1, _hurd_select (nfds=7, pollfds=0x0,
> readfds=0x103cc20, writefds=0x103cc40, exceptfds=0x103cc60,
> timeout=0x103cba4, sigmask=0x0) at ./hurd/hurdselect.c:51
> 51 ./hurd/hurdselect.c: No such fi
Hi,
I'm trying to track the curl failed tests by debugging select() function
(or system call?) defined in glibc using gdb. When I executed `b _hurd_select`
to set a break point and run the program. The gdb stopped at the breakpoint
but it gives me the following info:
```
Thread 2 hit Breakpoint 1
27 matches
Mail list logo
