Re: How to use the old termdebug

[Ernie Rael]

I've got a patch which includes both the legacy and vim9script 
termdebug. I set it up so by default one gets the legacy version. If you 
want the new version, you can something like:


   gvim -c "set co=220" -c "packadd termdebug9" -c "Termdebug9 $cmd $core"

I did it like this so existing users get the more reliable version that 
they are familiar with.


But, given the state of the tree, it's cleaner to add legacy as 
termdebug8 (or whatever). But if someone runs into trouble with the vim9 
version, they won't know about how to use the old one. It's simple to PR 
either way.


There's only two very small outstanding PRs against the current setup, 
so that shouldn't be an issue. If needed I can port them


   fix: [termdebug] id/subid maybe mis-match type #15015
   fix: [termdebug] correct K/-/+ mappings check #15013

Comments/preferences/suggestions appreciated.

-ernie

On 24/06/12 11:44 AM, Ernie Rael wrote:


I used termdebug yesterday for some real work. Before opening issues, 
I'd like to verify/check if these are old/new issues; I don't remember 
having seen them, so I'm thinking new. Is there a convenient way to 
run the old and new side by side?


Some things I saw yesterday are

  * stack up/down occasionally takes around two seconds
  * current execution line, or frame current line, not always highlighted
  * E1013: Argument 1: type mismatch, expected number but got string
  * Error detected while processing BufRead Autocommands for
"*"..function 41_BufRead:

These could all be a single problem. I have a pretty vanilla setup...

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/53f865db-defc-42fd-b9ed-f7b33f77a4ca%40raelity.com 
<https://groups.google.com/d/msgid/vim_dev/53f865db-defc-42fd-b9ed-f7b33f77a4ca%40raelity.com?utm_medium=email&utm_source=footer>.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/fe9f6b5e-78cc-41f7-8e6c-c6b06cbf8c82%40raelity.com.

Is there an alternative to "execute 'buffer' this.bufnr"

[Ernie Rael]

I was looking for a function that could be used instead of

   execute 'buffer' this.bufnr

Is there a function that puts a buffer into a window? As a longshot I tried

   bufload(this.bufnr)

It was not pretty.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/f1f1269a-b09d-4ee5-b53d-313ec0204707%40raelity.com.

Re: How to use the old termdebug

[Ernie Rael]

On 24/06/12 11:59 AM, Christian Brabandt wrote:

On Mi, 12 Jun 2024, Ernie Rael wrote:


I used termdebug yesterday for some real work. Before opening issues, I'd
like to verify/check if these are old/new issues; I don't remember having
seen them, so I'm thinking new. Is there a convenient way to run the old and
new side by side?

Some things I saw yesterday are

  * stack up/down occasionally takes around two seconds
  * current execution line, or frame current line, not always highlighted
  * E1013: Argument 1: type mismatch, expected number but got string
  * Error detected while processing BufRead Autocommands for
"*"..function 41_BufRead:

These could all be a single problem. I have a pretty vanilla setup...

Those are probably fallout from the recent conversion to Vim9 script.


Right, is there a convenient way to run the pre-conversion termdebug, 
without getting rid of the new one. I want to provide accurate issue 
reports. (and if needed ...)


-ernie



Thanks,
Christian



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/eb19cfee-cc3e-44ab-8ffc-8e3f1d56db97%40raelity.com.

How to use the old termdebug

[Ernie Rael]

I used termdebug yesterday for some real work. Before opening issues, 
I'd like to verify/check if these are old/new issues; I don't remember 
having seen them, so I'm thinking new. Is there a convenient way to run 
the old and new side by side?


Some things I saw yesterday are

 * stack up/down occasionally takes around two seconds
 * current execution line, or frame current line, not always highlighted
 * E1013: Argument 1: type mismatch, expected number but got string
 * Error detected while processing BufRead Autocommands for
   "*"..function 41_BufRead:

These could all be a single problem. I have a pretty vanilla setup...

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/53f865db-defc-42fd-b9ed-f7b33f77a4ca%40raelity.com.

Re: test_vim9_func.vim seems to be weird in github repository

[Ernie Rael]

On 24/06/12 9:05 AM, Christian Brabandt wrote:

On Mi, 12 Jun 2024, Ernie Rael wrote:


I use "hg-git" so that may contribute to what I'm seeing.

But I've tried this on a few files and only this one file has an issue.

I mad a tiny change to test_vim9_func.vim, and when I diff I get

$ hg diff | head -5
diff --git a/src/testdir/test_vim9_func.vim
b/src/testdir/test_vim9_func.vim
index

d07bbfba70705d5d371e25907ebb6f9f3ba4cb69..cb75bad01b8374ece9f84f6ac084a65eb8615490
GIT binary patch
literal 107940
zc%1FM{d?Os(kOa=_FsW2XG^J397%TKL~oOBn#A3nZIeAsy6t@&zj`Q%wpmN0mZWTX

I tried this both on a local clone of the main vim repo and a clone of my
fork of the vim repo.

I don't know git (and am not interested in learning it, quite the opposite).

If anyone can provide some insight on why I'm seeing "*GIT binary patch*"
for this one file...

This is probably because of the ASCI NUL characters in the
Test_invalid_redir() function, which cause git/hg to detect this file as
non-ascii and therefore creates this binary patch. In git, one could
mark it as text, but not sure if a patch would then still work if it
affects those characters. On the other hand, I would hope, that git/hg
is hopefully fine importing such a binary patch.


Ah, thanks.

I was concerned that it was some kind of metadata issue with the file 
and not the file itself.


"hg diff" has an option to treat all files as text (now I know (till I 
forget)).


-ernie



Thanks,
Christian



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5c0ff4a7-5e87-4c0b-b585-bd4142911134%40raelity.com.

test_vim9_func.vim seems to be weird in github repository

[Ernie Rael]

I use "hg-git" so that may contribute to what I'm seeing.

But I've tried this on a few files and only this one file has an issue.

I mad a tiny change to test_vim9_func.vim, and when I diff I get

   $ hg diff | head -5
   diff --git a/src/testdir/test_vim9_func.vim
   b/src/testdir/test_vim9_func.vim
   index
   
d07bbfba70705d5d371e25907ebb6f9f3ba4cb69..cb75bad01b8374ece9f84f6ac084a65eb8615490
   GIT binary patch
   literal 107940
   zc%1FM{d?Os(kOa=_FsW2XG^J397%TKL~oOBn#A3nZIeAsy6t@&zj`Q%wpmN0mZWTX

I tried this both on a local clone of the main vim repo and a clone of 
my fork of the vim repo.


I don't know git (and am not interested in learning it, quite the opposite).

If anyone can provide some insight on why I'm seeing "*GIT binary 
patch*" for this one file...


-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/a6dae2c1-7bbb-41ad-bdf7-d0c046d7e49b%40raelity.com.

Re: Test on

[Ernie Rael]

On 24/04/17 4:17 PM, Ernie Rael wrote:
There's a test failure on window, but not on Linux or MacOS, related 
to a PR I opened.



Failures:
    From test_vim9_import.vim:
    Found errors in Test_autoload_import_relative_compiled():
    Caught exception in Test_autoload_import_relative_compiled(): 
Vim(import):E282: Cannot read from ":xfile.vim" @ command 
line..script D:/a/vim/vim/src/testdir/runtest.vim[607]..function 
RunTheTest[57]..Test_autoload_import_relative_compiled[22]..script 
:source buffer=3, line 3


I've got no idea what's going on. Any hints or clues?

-ernie


Oops, and for reference

   https://github.com/vim/vim/pull/14579

   https://github.com/vim/vim/actions/runs/8729713065/job/23952210362?pr=14579

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/7b705e44-6306-4e00-9a9f-cffb5bf340a2%40raelity.com.

Test on

[Ernie Rael]

There's a test failure on window, but not on Linux or MacOS, related to 
a PR I opened.



Failures:
    From test_vim9_import.vim:
    Found errors in Test_autoload_import_relative_compiled():
    Caught exception in Test_autoload_import_relative_compiled(): 
Vim(import):E282: Cannot read from ":xfile.vim" @ command line..script 
D:/a/vim/vim/src/testdir/runtest.vim[607]..function 
RunTheTest[57]..Test_autoload_import_relative_compiled[22]..script 
:source buffer=3, line 3


I've got no idea what's going on. Any hints or clues?

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6e2cd1a5-e608-4ace-a2a2-d8bbb486d4de%40raelity.com.

problem with vim_dev delivery

[Ernie Rael]

I just sent something to vim_dev that was rejected by "Google Groups". 
Apologies if you see this; to track this down, I'm just checking to see 
if everything I send is rejected.


-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/9c6445b2-b20a-4b1d-b6e3-bbb7806a5c82%40raelity.com.

Splice9 merge tool v0.9 released

[Ernie Rael]

Splice9 is a 3 way merge tool. Splice9 v0.9 [1] is a pure vim9script port of
Splice [2] with some additional interactive features. The only changes since
v0.9-RC2 (3 months old) are updating syntax for vim9.1.

v0.9 is released as a zip file. Maybe by v1.0 I'll learn the proper way to
release a plugin:)

-ernie

[1] https://github.com/errael/splice9/releases/tag/v0.9
[2] https://docs.stevelosh.com/splice.vim

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/aaf3ce99-b5bd-4895-9efc-9e32e6447dd5%40raelity.com.

Re: error pulling

[Ernie Rael]

On 23/12/28 3:48 PM, tooth pik wrote:

is anyone else getting this:


I don't use github, but in mercurial I frequently get "modified" status 
for a file in src/po after some combo of pull/build/update. I revert the 
file to get rid of the change. Not sure what causes it, build/makefile?


-ernie



Updating 7d0abf2cb..7e4f62a25
error: Your local changes to the following files would be overwritten 
by merge:

        src/po/ru.cp1251.po
Please commit your local changes or stash them before you merge.
Aborting
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CALfSX1xEnVco0KxsKu443pGv0OqefyPC%3DsuvDQUjdqZTRsCphw%40mail.gmail.com 
.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/b8e1d615-78db-4095-95af-6589dcf47f4f%40raelity.com.

Re: After applying patches 9.0.2168 to 9.0.2173 : warning -Wmaybe-uninitialized in vim9cmds.c (not in Tiny)

[Ernie Rael]

On 23/12/16 6:26 PM, Yegappan Lakshmanan wrote:

Hi Tony,

On Sat, Dec 16, 2023 at 3:50 PM Tony Mechelynck 
 wrote:


vim9cmds.c: In function ‘compile_defer’:
vim9cmds.c:2051:18: warning: ‘type’ may be used uninitialized
[-Wmaybe-uninitialized]
 2051 |         else if (check_func_args_from_type(cctx, type,
argcount, TRUE,
      | ^
 2052 |                     arg_start) == FAIL)
      |                     ~~
vim9cmds.c:2003:18: note: ‘type’ was declared here
 2003 |     type_T      *type;
      |                  ^~~~


Which environment and compiler are you using? I don't see this 
warning.  "type" is
initialized at line 2027 and used at line 2051.  We can initialize 
"type" to NULL at line 2003.

But I don't think this is necessary.


I see this as well. Using gcc. The problem is that the initialization is 
inside


   if (cctx->ctx_skip != SKIP_YES)

It's true that the use is also inside that condition, so there's no 
/real/ problem (assuming ctx_skip isn't changed by the intervening 
function calls.


-ernie



Regards,
Yegappan

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAAW7x7%3DkERn01BC_ZAkZxh9A9EYoXUDza-BgeSic160nsoDnug%40mail.gmail.com 
.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/0c49e6d1-b3a4-494b-b95a-1f5d577a64b7%40raelity.com.

Re: Overflow detection issue in 9.0.2111, 9.0.2109

[Ernie Rael]

Hi Michael,

I appreciate seeing your analysis; I did a flawed analysis. I screwed up 
trying to get it "perfect" with a single compare.


I just tried the following as a single compare at entry (derived from: x 
* 10 + digit <= max)


   if (x > ((INT_MAX - digit) / 10)) return FAIL;

AFAICT, it replicates  your results without a separate check for 
addition. If I make it constant


   if (x > ((INT_MAX - 9) / 10))

then you only lose less than 10 valid numbers, and get a single compare 
with no runtime calculations in the generated code.


int: 214748363:4 = 2147483634 <= 2147483647
int: 214748363:5 = 2147483635 <= 2147483647
int: 214748363:6 = 2147483636 <= 2147483647
int: 214748363:7 = 2147483637 <= 2147483647
int: 214748363:8 = 2147483638 <= 2147483647
int: 214748363:9 = 2147483639 <= 2147483647
int: 214748364:0 > 2147483647 (FAIL) 2147483640
int: 214748364:1 > 2147483647 (FAIL) 2147483641
int: 214748364:2 > 2147483647 (FAIL) 2147483642
int: 214748364:3 > 2147483647 (FAIL) 2147483643
int: 214748364:4 > 2147483647 (FAIL) 2147483644
int: 214748364:5 > 2147483647 (FAIL) 2147483645
int: 214748364:6 > 2147483647 (FAIL) 2147483646
int: 214748364:7 > 2147483647 (FAIL) 2147483647
int: 214748364:8 > 2147483647 (FAIL) -2147483648
int: 214748364:9 > 2147483647 (FAIL) -2147483647

Make it an inline function so the compiler can have its way with it and 
the generated code is pretty small.


Does this make sense to you?

-ernie


On 23/11/16 2:40 PM, Michael Henry wrote:

All,

I noticed these two patches too late to comment on the associated pull
request:

- patch 9.0.2111: [security]: overflow in get_number:
- patch 9.0.2109: [security]: overflow in nv_z_get_count:

Both perform overflow detection similarly, verifying that multiplication
by 10 does not overflow; in both cases, the detection logic lacks a
necessary extra check to ensure the addition of the new digit value does
not overflow.

For the `int` case, on a typical box with 32-bit `int` the value of
`INT_MAX` will be 2147483647.  Consider the case where all but the last
`7` has been typed; the current value is then 214748364, which is no
greater than `INT_MAX/10`, so another digit is accepted.  Multiplying by
10 yields 21474836470.  Any digit up to `7` will remain in range, but
`8` and `9` will cause overflow.  Similar logic applies for the `long` case.

The below example program shows helper functions for detecting whether a
given value (`int` or `long`) can accept another digit.

```c
#include 
#include 

#define OK   1
#define FAIL 0

#define CHECK_ADDITION 1

int
vim_append_digit_int(int *value, int digit)
{
     int x = *value;
     if (x > (INT_MAX / 10))
     return FAIL;
     x *= 10;
#if CHECK_ADDITION
     if (x > (INT_MAX - digit))
     return FAIL;
#endif
     x += digit;
     *value = x;
     return OK;
}

int
vim_append_digit_long(long *value, int digit)
{
     long x = *value;
     if (x > (LONG_MAX / 10))
     return FAIL;
     x *= 10;
#if CHECK_ADDITION
     if (x > (LONG_MAX - digit))
     return FAIL;
#endif
     x += digit;
     *value = x;
     return OK;
}

static void
testInt(int value, int digit)
{
     int oldValue = value;
     int success = vim_append_digit_int(&value, digit);
     if (success)
     {
     printf("int: %d:%d = %d <= %d\n", oldValue, digit, value, INT_MAX);
     }
     else
     {
     printf("int: %d:%d > %d (FAIL)\n", oldValue, digit, INT_MAX);
     }
}

static void
testLong(long value, int digit)
{
     long oldValue = value;
     int success = vim_append_digit_long(&value, digit);
     if (success)
     {
     printf("long: %ld:%d = %ld <= %ld\n", oldValue, digit, value,
LONG_MAX);
     }
     else
     {
     printf("long: %ld:%d > %ld (FAIL)\n", oldValue, digit, LONG_MAX);
     }
}

int
main(void)
{
     testInt(INT_MAX / 10, 0);
     testInt(INT_MAX / 10, INT_MAX % 10);
     testInt(INT_MAX / 10, INT_MAX % 10 + 1);
     testLong(LONG_MAX / 10, 0);
     testLong(LONG_MAX / 10, LONG_MAX % 10);
     testLong(LONG_MAX / 10, LONG_MAX % 10 + 1);
     return 0;
}
```

On my 64-bit Ubuntu Linux machine, I get the following output:

```
int: 214748364:0 = 2147483640 <= 2147483647
int: 214748364:7 = 2147483647 <= 2147483647
int: 214748364:8 > 2147483647 (FAIL)
long: 922337203685477580:0 = 9223372036854775800 <= 9223372036854775807
long: 922337203685477580:7 = 9223372036854775807 <= 9223372036854775807
long: 922337203685477580:8 > 9223372036854775807 (FAIL)
```

In the sample program change `CHECK_ADDITION` to `0` to demonstrate the
need for the second check.

Michael Henry



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To v

Re: [vim/vim] Update usr_51.txt (PR #13496)

[Ernie Rael]

On 23/11/07 10:29 AM, Marvin Renich wrote:

a pronoun, [they], that has since the beginning of the English language been
specifically plural,


That statement is inaccurate; it's as though you're saying English 
sprang into existence fully formed and did not evolve. See 
https://en.wikipedia.org/wiki/Singular_they (or some of the several 
other references).


It would be useful if those taking the position that "they/their" should 
not be used would provide some supporting references.


-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/cc07edd5-7587-4d57-9ebf-363cbdfe8153%40raelity.com.

Re: Is there a vim9.1 release plan/requirements?

[Ernie Rael]

On 23/10/31 3:21 AM, Christian Brabandt wrote:

On So, 29 Okt 2023, Ernie Rael wrote:


Greetings programs,

A vim9.1 release has vim9script and everything else. I have little sense of
what "everything else" is in this context; I have recently seen
"complete_info" and "safe executable check". Is there much that needs to be
done for vim9.1 (not considering vim9script)?

No, that doesn't need to go to 9.1. But the complete_info fix seems
small enough and as a bug fix should qualify.
Those were simply two things I recently saw. Just pointing out that 
there could well be things pending that need to get into vim9.1.



Just opened "Language Specification: vim9.1 vim9script freeze"[1] to discuss
whether or not vim9script is in a good position to freeze and release; along
with what might be needed to get there and/or polish it up. I hope the
community contributes.

Throwing a dart at the wall, I'd look for 2 weeks of cleanup/fixes and 2
weeks of freeze where only significant fixes go in with a Nov 1 release.
Assumes the current "single branch" repo model is used.


You mean Dec 1?

(Yikes, glad I didn't put a year in there somewhere.) Yes, for instance.

  Other than that, that sound reasonable. Assuming the Vim
9 specs are considered feature complete (I trust Yegappan here), this
makes sense and I would only include clear bug fixes + runtime file
updates + security updates. However, I need to find out, what has to be
done for a 9.1 release (updating version9.txt including all patches and
consistently updating all the naming issues). I don't know how much work
that is. I guess we all have to learn something here

Thanks,
Christian



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/3f96e7f2-e532-42e2-bc70-6eb8744faee6%40raelity.com.

Is there a vim9.1 release plan/requirements?

[Ernie Rael]

Greetings programs,

A vim9.1 release has vim9script and everything else. I have little sense 
of what "everything else" is in this context; I have recently seen 
"complete_info" and "safe executable check". Is there much that needs to 
be done for vim9.1 (not considering vim9script)?


Just opened "Language Specification: vim9.1 vim9script freeze"[1] to 
discuss whether or not vim9script is in a good position to freeze and 
release; along with what might be needed to get there and/or polish it 
up. I hope the community contributes.


Throwing a dart at the wall, I'd look for 2 weeks of cleanup/fixes and 2 
weeks of freeze where only significant fixes go in with a Nov 1 release. 
Assumes the current "single branch" repo model is used.


The MCP will have to contemplate, meditate, and otherwise look at the 
situation and make a scheduling decisions.


[1] "Language Specification: vim9.1 vim9script freeze" 
https://github.com/vim/vim/discussions/13454


-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/d4f7b67c-c73c-48ee-8be0-5282029c34f2%40raelity.com.

Struct/Union initialization

[Ernie Rael]

Greetings,

In ":he develop", under C99 "Not to be used", I don't see "designated 
initializers".


Is it OK to use that feature?

I'm working with a newly added struct and using that minimizes the 
support burden considerably. If it hasn't been vetted, I'm only working 
with one struct and this could be the canary in the coal mine.


-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/8fc24bdf-2a66-d181-7efd-13435fafe753%40raelity.com.

unexpected way to append to a list

[Ernie Rael]

I was surprised that this works to append to a list

   vim9script

   var l2 = []
   l2[0] = 3
   echo l2

   l2 = [1, 2, 3]
   l2[3] = 4
   echo l2

Unless a recent change introduced this bug, it probably shouldn't be fixed.

Should it be documented?

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/955250f0-753f-d4c6-2fe0-9065dbacaa57%40raelity.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Ernie Rael]

On 23/10/01 2:56 PM, Yegappan Lakshmanan wrote:


On Sun, Oct 1, 2023 at 11:06 AM Ernie Rael  wrote:

On 23/10/01 6:44 AM, Yegappan Lakshmanan wrote:

Hi,

On Sun, Oct 1, 2023 at 5:17 AM shane qian 
wrote:

and I meant vim9script so far I felt it's good for
type-checking and performance, but vim9 class to me I felt a
bit burdened, not sure if still a chance to make it be simple
to use (use for scripting), still wish that's the goal.
@errael  @yegappan


I haven't introduced any fancy OOP features so far.  These are
the features
that Bram has partially implemented or planned for and were
already in
the todo list.


The spec clearly says (said)

Object methods of the base class can be overruled. *The
signature (arguments,**
**argument types and return type) must be exactly the same*. 
The method of the
base class can be called by prefixing "super.".

I can't find where Bram partially implemented or planned to allow
contravariant parameters. In fact it looks the other way around.
See comments
https://github.com/vim/vim/pull/13221#issuecomment-1741637630 .

After we've all worked hard to resolve incomplete spec issues
(thinking statics) and to get the implementation to meet the spec.
This last minute spec change, which doesn't seem to offer any
useful functionality and hasn't been discussed or tested, feels
ill-conceived.


We have two options for the method parameter types.



Actually, we have *three options*. We could follow the original spec 
which is invariant parameters: The signature [...] must be exactly the same.


I've been repeating myself. But I still have not seen any answer as to 
why the spec, invariant parameters, should be changed rather than simply 
enforcing the spec for vim9.1, and revisiting
the issue at some future point. I'd be interested in seeing a real world 
example that makes this

change worthwhile.

To be clear, if a method signature says "def Foo(): return A", that 
doesn't mean that a subclass of A can't be returned from Foo().



We can either follow the Typescript/Java
specification, which supports covariance for the method parameters or 
follow the Dart specification
which supports contra-variance for the method parameters.  As we are 
already following the Dart

specification for interfaces, I choose the Dart specification.


So what if we chose Dart for one thing. There are some cases where other 
languages are followed, the idea is to pick something consistent with 
the vim9script design philosophy. I do not understand why change the 
spec for a confusing concept. I've only seen contravariant parameters in 
relationship to generics, for example


   In the common case of a generic data structure ilist, covariant
   parameters are used for methods getting data out of the structure,
   and contravariant parameters for methods putting data into the
   structure. the mnemonic for Producer Extends, Consumer Super (PECS),
   from the book Effective Java by Joshua Bloch gives an easy way to
   remember when to use covariance and contravariance.

But in our case we are not talking about a generic data structures. And 
no matter what words you use to describe it, it is not a simple concept. 
I still review PECS when I design a Java generic class/method. IIRC, 
generics are on the vim9class todo list; that's probably the proper time 
to consider contravariant parameters.


-ernie


While this may be something for the future, /I see no reason to
change the spec now/.


These features are basic to any OOP language.


Can you point to a language that doesn't have overloaded methods
that allows contravariant parameters? I'm not saying there aren't
any (I'm just a country language-lawyer).


Are you referring to covariant parameters here?  If you are, then Dart 
allows only contravariant parameters

for overloaded methods.

Regards,
Yegappan


[...]
I think using a formal type checking term like "covariance" and
"contra-variance"
confuses people to think that we are introducing fancy features. 
But these are
just terms for describing the type check and not new features.


I don't believe that is accurate regarding contra-variant
parameters; that is new. And for returning a covariant type that
could already be done *without removing the requirement* that "the
signature ... must be exactly the same".



  I could have
used "implement appropriate type check for method arguments and
return
types in extended classes".


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/mailli

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Ernie Rael]

On 23/10/01 8:02 AM, shane qian wrote:
1. we may ask core members to vote, if class is just a struct then no 
all of those arguments. these were all gone. :smile:


2. it was just saying **default** was to be `public`, didn't mean no 
`private`.


3. if `new()` is accessed only by `new C`, empty()/length() perhaps 
can be limited to only internal use too.


I haven't yet looked at the empty()/len() addition; this /was/ in the 
todo list. I'm guessing this allows the programmer to do


   class C...
   len(obj_of_type_C)

and get a value defined by the class, could be very handy for a class 
that is used as a container. Not sure what happens if class didn't 
define a __len function; guess I'll find out.


What I don't understand is why these spec changes are needed at the last 
minute. Seems better to add them after 9.1 is released.


Unless the idea is to wait several months to shake out these  new 
additions. Something being in the todo list does not always imply it 
gets into a release. Unless it's a simple change, I'd think that stuff 
would go in at the beginning of the release cycle and not the end.


-ernie



anyway, let's listen someone else if there were, or I am worried 
what's the end this OOP of vim9 how it would be easy to use.
// and sorry I am actually not sure why I was joining to argue this 
too, aha... maybe there  no job to bother me. :lol:


--
shane.xb.qian

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/OS3P286MB0913D94F71C3B843152D4D72EBC6A%40OS3P286MB0913.JPNP286.PROD.OUTLOOK.COM 
.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/01dae889-b206-f820-4029-fc756991dd6f%40raelity.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Ernie Rael]

On 23/10/01 6:44 AM, Yegappan Lakshmanan wrote:

Hi,

On Sun, Oct 1, 2023 at 5:17 AM shane qian  wrote:

and I meant vim9script so far I felt it's good for type-checking
and performance, but vim9 class to me I felt a bit burdened, not
sure if still a chance to make it be simple to use (use for
scripting), still wish that's the goal. @errael @yegappan


I haven't introduced any fancy OOP features so far. These are the features
that Bram has partially implemented or planned for and were already in
the todo list.


The spec clearly says (said)

   Object methods of the base class can be overruled. *The signature
   (arguments,**
   **argument types and return type) must be exactly the same*. The
   method of the
   base class can be called by prefixing "super.".

I can't find where Bram partially implemented or planned to allow 
contravariant parameters. In fact it looks the other way around. See 
comments

https://github.com/vim/vim/pull/13221#issuecomment-1741637630 .

After we've all worked hard to resolve incomplete spec issues (thinking 
statics) and to get the implementation to meet the spec. This last 
minute spec change, which doesn't seem to offer any useful functionality 
and hasn't been discussed or tested, feels ill-conceived.


While this may be something for the future, /I see no reason to change 
the spec now/.



These features are basic to any OOP language.


Can you point to a language that doesn't have overloaded methods that 
allows contravariant parameters? I'm not saying there aren't any (I'm 
just a country language-lawyer).



[...]
I think using a formal type checking term like "covariance" and 
"contra-variance"
confuses people to think that we are introducing fancy features.  But 
these are

just terms for describing the type check and not new features.


I don't believe that is accurate regarding contra-variant parameters; 
that is new. And for returning a covariant type that could already be 
done *without removing the requirement* that "the signature ... must be 
exactly the same".




  I could have
used "implement appropriate type check for method arguments and return
types in extended classes".

Regards,
Yegappan
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAAW7x7%3DEMWHk1FmdAfyuZesgyon8BFeB06GUqxsVMULOpasS_A%40mail.gmail.com 
.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/19d82b24-7b63-49f3-2334-73e130a0b160%40raelity.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Ernie Rael]

On 23/09/30 3:55 AM, Christian Brabandt wrote:

On Fr, 29 Sep 2023, Ernie Rael wrote:



I always freak out when I don't see a response I made show up in the list.
So just in case the it wasn't delivered for some reason, there's a TL;DR
response at

https://github.com/vim/vim/pull/13221#issuecomment-1741637630

(apologies for the noise if it was delivered)

Well, make sure your reply includes the github mailing address, it
should look like this:
reply+xx...@reply.github.com

and then the reply should go through

Best,
Christian


I wasn't clear, sorry. I posted something at github, and didn't see it 
show up in vim_dev; so the other direction. Once and a while stuff I 
post on github doesn't make it to vimdev; I haven't noticed a pattern.


-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/51c9c7d3-301a-64e8-12ea-88c65312345e%40raelity.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Ernie Rael]

On 23/09/29 6:29 PM, Yegappan Lakshmanan wrote:

I always freak out when I don't see a response I made show up in the 
list. So just in case the it wasn't delivered for some reason, there's a 
TL;DR response at


https://github.com/vim/vim/pull/13221#issuecomment-1741637630

(apologies for the noise if it was delivered)

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/d9bfff96-d654-e029-456e-6c4d23f1412b%40raelity.com.

Re: Commit: patch 9.0.1955: Vim9: lockvar issues with objects/classes

[Ernie Rael]

On 23/09/29 11:00 AM, Christian Brabandt wrote:

patch 9.0.1955: Vim9: lockvar issues with objects/classes


To summarize

This PR gives these vim9script vim9class semantics for lockvar in vim9.1

 * lockvar of a class or object does nothing and no error.
   A possible future extension would allow a class to hook into
   lockvar, as suggested for len() and empty() in todo
 * handle lockvar of :def argument and other expected scenarios.
 * lockvar of a class/object variable is an error.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/1b643bb9-d28d-8acb-a7b7-005dfc4ce82e%40raelity.com.

Found errors in Test_glob_extended_bash():

[Ernie Rael]

Since this recently started killing the "macos" and "windows" tests, I'm 
guessing that has to do with the '**' handling.


-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/33752974-e2a9-b1ea-4039-0cb0089f5988%40raelity.com.

lockvar on a function arg

[Ernie Rael]

Here's a legacy script that has a function that locks it's argument 
which is a dictionary in this example. Since this is probably the most 
complex legacy script I've written, I want to make sure it's 
expected/good behavior. (the proceeding after an error is spooky, but 
convenient...)


Asking because vim9script doesn't handle it.

-ernie

   func Lock(x)
    lockvar a:x
   endfunc

   let val = {'a': 99}

   call Lock(val)

   call extend(val, {'b': 100})
   echo val
   let val = {'c': 101}
   echo val

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/2e6291ac-7f83-8853-d014-fb2d22d8a30e%40raelity.com.

lockvar/unlockvar

[Ernie Rael]

Hi all,

I'm wondering if I'm seeing an error

":help lockvar" seems to indicate that the following should work.
The goal is to get a writable variable "l1" that holds a locked list.

    vim9script
    var l0: list> = [ [1, 2, 3], [4, 5, 6], [7, 8, 9] ]
    var l1 = l0
    lockvar! l1
    unlockvar 0 l1  # < expect "l1" writable, list still locked

    # Not modifying the value, but gets a value locked error
    l1 = null_list  # E741: Value is locked: l1

Can do it this way

    vim9script

    var l0: list> = [ [1, 2, 3], [4, 5, 6], [7, 8, 9] ]
    lockvar! l0
    var l1 = l0

    #l1[0] = []  # fails as exepcted
    l1 = null_list  # works as expected

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ff22fece-5b16-b52d-dbd3-59e7780b3ead%40raelity.com.

Re: bell(), looking for builtin function to ring the bell

[Ernie Rael]

On 23/09/13 10:48 AM, Gary Johnson wrote:

I use

 normal \

but I don't know how cross-platform it is.  It's documented at

 :help :echoerr

You don't have to use :exe.  I surround it with a test for
'errorbells', e.g.,

 if &errorbells
 normal \ " Generate a bell
 endif
 echohl ErrorMsg
 echomsg "Oops!"
 echohl None


Thanks.

-ernie



Regards,
Gary



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/8b62bb86-31db-038f-5598-7d17775b6469%40raelity.com.

bell(), looking for builtin function to ring the bell

[Ernie Rael]

Greetings,

In a plugin I'm working on, when certain simple errors occur, I want to 
ring the bell, some kind of alert. A popup, use in some place in the 
plugin, is more than is needed.


The closest thing I can find is

   call sound_playevent('bell')

which isn't cross platform.

What have I missed?

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/06f8b4df-662b-1479-dca5-65869898a160%40raelity.com.

vim9class work/bugs/todo update

[Ernie Rael]

The number of open vim9script spec syntax/semantics issues has gone from 
1 to 3. Sigh.


https://github.com/vim/vim/discussions/13041

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/1380b900-821f-3960-3c5a-6f7d4d810157%40raelity.com.

Re: locally failing test_vim9_builtin

[Ernie Rael]

On 23/09/10 10:31 AM, Christian Brabandt wrote:

On So, 10 Sep 2023, Ernie Rael wrote:


If I run a shell script

unset DISPLAY
make test_vim9_builtin

The error does not occur. Thanks.

This, explains (I'm waving my hands) that when doing `make
test_vim9_builtin` some random gvim pops up to the foreground. Out of
curiosity, I'll look at Test_remote_expr (or at least put it on a todo list)
since I have no idea what feature I'm unfamiliar with is being tested.

It is using the remote expression feature, that only works with a X11
server. Not clear why it doesn't work correctly in your case. Are you
possibly using Wayland instead?


Not wayland. I'm running a vanilla System76 popOS

   $ env|grep XDG_SESSION
   XDG_SESSION_DESKTOP=pop
   XDG_SESSION_TYPE=x11
   XDG_SESSION_CLASS=user

Executing from the default console (I guess xterm is long gone), ps has

   /usr/bin/gnome-terminal.real

plus hundreds of other things.

-ernie



I usually don't run the tests in a X11 session, so I don't know if there
is something wrong with the test (or your Environment).

Thanks,
Christian


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/b78b6345-754d-903a-4d97-828b9b63973e%40raelity.com.

Re: locally failing test_vim9_builtin

[Ernie Rael]

On 23/09/10 9:51 AM, Christian Brabandt wrote:

On Sa, 09 Sep 2023, Ernie Rael wrote:


Hi all,

I'll often do:

make $(ls test_vim9*.vim | sed 's/\.vim$//' | grep -v vim9_builtin)

I need to exclude test_vim9_builtin because I typically get the errors, see
below. Any idea on what's going on?

-ernie


Found errors in Test_remote_expr():

Not sure how you run it,


I do

   make test_vim9_builtin

If I run a shell script

   unset DISPLAY
   make test_vim9_builtin

The error does not occur. Thanks.

This, explains (I'm waving my hands) that when doing `make 
test_vim9_builtin` some random gvim pops up to the foreground. Out of 
curiosity, I'll look at Test_remote_expr (or at least put it on a todo 
list) since I have no idea what feature I'm unfamiliar with is being tested.


-ernie


but it seems Vim cannot connect to another Vim
Server. Perhaps trying unsetting $DISPLAY (or not running it in your X11
session).

Best,
Christian


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/0af6f70c-26ed-ad48-9e4f-302854e7216b%40raelity.com.

locally failing test_vim9_builtin

[Ernie Rael]

Hi all,

I'll often do:

   make $(ls test_vim9*.vim | sed 's/\.vim$//' | grep -v vim9_builtin)

I need to exclude test_vim9_builtin because I typically get the errors, 
see below. Any idea on what's going on?


-ernie

Abbreviating the errors so maybe it will get passed by the google groups 
filter


Found errors in Test_remote_expr():
[...]Expected 'E241: Unable to send to ' but got 'E449: Invalid 
expression received'
[...]Test_remote_foreground line 8: command did not fail: 
remote_foreground("")

Found errors in Test_remote_send():

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/be5254aa-dd33-a2a5-fa67-c6493eed98fa%40raelity.com.

Re: Splice9 merge tool

[Ernie Rael]

On 23/08/28 12:13 PM, Christian Brabandt wrote:

On So, 27 Aug 2023, Ernie Rael wrote:


Greetings,

In March of 2022 I started porting Splice[1], a 3 way merge tool written in
vim/python, to vim9script.[...]

[1] https://docs.stevelosh.com/splice.vim/

Is that a request to package this with Vim? ;)

I would be interested into trying this out, as I have had to fix a few
conflicts already, but I just used the git mergetool -t vimdiff (which
worked surprisingly well, once one knows what all those different files
are)

Best,
Christian


There's an RC1 release of Splice9[1], a pure vim9script implementation. 
I've got it set to minimal patch level 1880. The repo's README has 
instructions on hooking it up to Git (or mercurial or bazzar). Enjoy, 
and of course let me know of any issues/questions and/or open an issue.


[1] https://github.com/errael/splice9/releases/tag/v0.9-RC1

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/4fcb64aa-88b0-d3c0-9814-d06c66336a26%40raelity.com.

New test problem: test_crash.vim: Found errors in Test_crash1():

[Ernie Rael]

New problem? Or is it just me?

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/fe5269d2-49c3-ec72-0477-ce2d8a4c8ea8%40raelity.com.

vim9class: accessing statics from outside the class

[Ernie Rael]

AFAICT, it doesn't work. Is anyone working on this?

I've run into it while working https://github.com/vim/vim/pull/13007.

I am taking a look, but I don't want duplicate efforts.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/49ac7706-b556-0166-984c-54598cf25d51%40raelity.com.

Re: Commit: patch 9.0.1842: Need more accurate profiling

[Ernie Rael]

On 23/09/02 6:15 AM, Christian Brabandt wrote:

patch 9.0.1842: Need more accurate profiling

Commit:https://github.com/vim/vim/commit/21d3212361f687704acb52cad7c1b9228e7c83f0
Author: Ernie Rael
Date:   Sat Sep 2 15:09:18 2023 +0200

 patch 9.0.1842: Need more accurate profiling
 
 Problem:  Need more accurate profiling

 Solution: Improve profiling results
 
 closes: #12192


The tables such as

   |=== assign micro-prof === 50-100 100-50 200-2 : nLoops-nKeys
   (usec/op) 0.036 0.040 0.039 : var local = n_value ###-A 0.037 0.035
   0.034 : local = C.static_var ###-D 0.059 0.055 0.050 : local =
   a_class.this_var ###-G 0.180 0.173 0.170 : local = a_class.Getter()
   ###-J|

Are produced by vim9script import and shell/gawk scripts found at

   https://github.com/errael/vim-microprof

The docs are minimal. If there is interest, the docs can be expanded. 
Otherwise it's there as is.


-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6aa825db-71b3-c56d-11e8-f64b4afc3251%40raelity.com.

Re: Updates on the Vim project

[Ernie Rael]

On 23/08/28 11:55 AM, Tony Mechelynck wrote:

On Thu, Aug 24, 2023 at 4:17 PM Ernie Rael  wrote:

On 23/08/24 2:44 AM, Tony Mechelynck wrote:

[...]
Well,  if the Mercurial mirror goes puff, I'll have to decide
either to fall back on the Vim from my distro (always somewhat behind,
currently 9.0.1632 and with a slightly different choice of features
than I would have chosen) or to start learning git seriously on a
fresh clone.

Have you considered the "hg-git" extension? "hg-git" on PyPi. It's had a
lot of work done in the last couple of years; it's in good shape,  with
regular releases. Also the newer "evolve" extension is useful, I use it
in favor of mq.

-ernie

I have used the mq extension, and it is OK for the uses I have, but
since I don't do actual "development" I use it rarely, and mostly for
typos in helpfiles, which I could just as well (but maybe a little
less practically for the maintainer) mention in purely "human readable
text" such as:
in file runtime/doc/foobar.txt, at line 1234
there is: azertyuiop wxcvbn
there should be: qwertyuiop wxcvbn

About using Mercurial on a git repo, I see that there is a "git"
extension distributed with Mercurial, but disabled by default and
labeled as "EXPERIMENTAL" in capitals in the output of "hg help
extensions". OTOH the output of "hg --config extensions.git=  help
git" is extremely terse to the point that it seems only meant to make
people afraid of it.
If that hg-git extension you mention is so good, why haven't the
Mercurial maintainers adopted it ? I daresay I have cold feet about
it.


If you ever feel like taking a chance, you could do this in parallel, 
you can do


1. Install hg-git (https://pypi.org/project/hg-git/ is a good starting
   place)
2. hg clone git+https://github.com/vim/vim.git [optional destination name]

Do "hg in", "hg pull", ..., whatever as usual.

-ernie



Christian, do you have any recommendations for someone who would want
to continue porting the changes from git to Mercurial if you ever
decide to close your own Mercurial mirror, or is it not worth the
trouble unless this new Mercurial mirror is made public (for instance
by maintaining a git mirror, exporting each patch as a set of diffs,
and importing that to a Mercurial clone) ? (I used to have a user site
but my ISP has closed it for no other reason than "if you want to
continue having a user site after DD/MM/, get into contact with us
before that date and an engineer of ours will build it for you". — I
was perfectly happy with building it slowly but surely by FTP and I
prefer to mind my own business, thank you.)


Best regards,
Tony.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/bb83df70-aa5d-8c76-ce54-8d5a340b88ab%40raelity.com.

Re: Updates on the Vim project

[Ernie Rael]

On 23/08/28 11:55 AM, Tony Mechelynck wrote:

On Thu, Aug 24, 2023 at 4:17 PM Ernie Rael  wrote:

On 23/08/24 2:44 AM, Tony Mechelynck wrote:

[...]
Well,  if the Mercurial mirror goes puff, I'll have to decide
either to fall back on the Vim from my distro (always somewhat behind,
currently 9.0.1632 and with a slightly different choice of features
than I would have chosen) or to start learning git seriously on a
fresh clone.

Have you considered the "hg-git" extension? "hg-git" on PyPi. It's had a
lot of work done in the last couple of years; it's in good shape,  with
regular releases. Also the newer "evolve" extension is useful, I use it
in favor of mq.

-ernie

I have used the mq extension, and it is OK for the uses I have, but
since I don't do actual "development" I use it rarely, and mostly for
typos in helpfiles, which I could just as well (but maybe a little
less practically for the maintainer) mention in purely "human readable
text" such as:
in file runtime/doc/foobar.txt, at line 1234
there is: azertyuiop wxcvbn
there should be: qwertyuiop wxcvbn

About using Mercurial on a git repo, I see that there is a "git"
extension distributed with Mercurial, but disabled by default and
labeled as "EXPERIMENTAL" in capitals in the output of "hg help
extensions". OTOH the output of "hg --config extensions.git=  help
git" is extremely terse to the point that it seems only meant to make
people afraid of it.
I've heard this is pretty basic, and local repositories built with it 
can't interact with normal mercurial repositories. Also that it doesn't 
handle git repos that have octopus merges/parentage (not sure what that 
is). But it seems like it might be satisfactory for usage with the vim 
repo for getting the latest.

If that hg-git extension you mention is so good, why haven't the
Mercurial maintainers adopted it ?


I'm not sure what you mean. Do you mean ship it with mercurial? I'm not 
sure of the relationship is among the people that work on mercurial 
components. I know mercurial is used by some large companies that fund a 
lot of the work. I can't answer your question, for all I know the answer 
is "they do".


I can say I've been using it with github for years, with several 
projects (I will never learn that devil spawned git) one of them is one 
of the largest project on github; I do PRs and all the regular 
development stuff.


That's an interesting question for the mercurial mailing list.

-ernie


I daresay I have cold feet about
it.
I admit to enjoying the bleeding edge; after all, I have vim9project 
that uses classes and should be ready to go with vim9.1.


Christian, do you have any recommendations for someone who would want
to continue porting the changes from git to Mercurial if you ever
decide to close your own Mercurial mirror, or is it not worth the
trouble unless this new Mercurial mirror is made public (for instance
by maintaining a git mirror, exporting each patch as a set of diffs,
and importing that to a Mercurial clone) ? (I used to have a user site
but my ISP has closed it for no other reason than "if you want to
continue having a user site after DD/MM/, get into contact with us
before that date and an engineer of ours will build it for you". — I
was perfectly happy with building it slowly but surely by FTP and I
prefer to mind my own business, thank you.)


Best regards,
Tony.



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/c345c0db-bcdd-d4fb-fbd6-76df342030c8%40raelity.com.

Re: Splice9 merge tool

[Ernie Rael]

On 23/08/28 12:50 PM, Christian Brabandt wrote:

On Mo, 28 Aug 2023, Ernie Rael wrote:

On 23/08/28 12:13 PM, Christian Brabandt wrote:
No, it wasn't. I've never published, or otherwise made available,
vimscript/vim9script (this is the first vim[9]script I've done). I have seen
a lot of talk in this forum on managing plugins and such and I'm wondering
what's the best way to do it.

Vim9 script should be pretty usable already. Except for OOP features, I
mean. I'd suggest you publish it somehwere to be able to get some
feedback.


Splice9 makes considerable use of vim9classes. When classes were first 
available last March I filed a bunch of issues. Only in the last few 
days have all the issues I filed been resolved. This last pending issue 
about access rules affects Splice9.


-ernie



Best,
Christian



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/1ff428e3-0858-6d76-fbdb-f4a0747ae905%40raelity.com.

Re: Splice9 merge tool

[Ernie Rael]

On 23/08/28 12:13 PM, Christian Brabandt wrote:

On So, 27 Aug 2023, Ernie Rael wrote:


Greetings,

In March of 2022 I started porting Splice[1], a 3 way merge tool written in
vim/python, to vim9script. I had never used vimscript and felt weak when it
came
to merging; so "two birds with one stone". There's now a pure vim9script
version. It has some UI enhancements.

I'm looking for suggestions/recommendations on setting it up for general
availability. Currently I've got everything under
~/pack/random-packages/start/splice-vim with one file in .../plugin and
everything else under .../autoload/splice9. All imports are relative to
facilitate having multiple versions installed.

I think using autoload for everything was a mistake and caused some of the
weird
errors I see when screwing around what get's imported and/or what get
declared
with proper type. In particular if in some file a variable gets exported and
the
file does imports, autoload can run into problems; now that Splice9 is
stable,
I'll play around with it. I'm guessing the right thing to do is put app
files
under import and "library" type files under autoload.

Splice9 is never, well, hardly ever, run from the command line. It it run by
the
version control tool. Currently I can have .../autoload/splice9 be a symlink
to
my VCS work area, very simple. But for general use I know there are a
variety of
ways to provide it, packadd and package managers, and I see this
EditorConfig
plugin that's now shipping with vim and I wonder if that's relevant, and
possibly a myriad of other approaches.

Anyway, suggestions and/or pointer to docs in this area that discuss best
practices appreciated.

Some of the Splice9 UI enhancements:
     - Additional status info (compact) in the HUD (Heads Up Display).
     - The action buttons in the HUD are clickable.
     - Rollover highlight for active HUD buttons.
     - Click for popup of shortcuts.
     - Can specify each action's ":map"/shortcut individually.
     - Can set "use meta" and the meta key is used instead of using
g:mapleader.
     - Version control system configuration the same as original Splice.

[1] https://docs.stevelosh.com/splice.vim/

Is that a request to package this with Vim? ;)


No, it wasn't. I've never published, or otherwise made available, 
vimscript/vim9script (this is the first vim[9]script I've done). I have 
seen a lot of talk in this forum on managing plugins and such and I'm 
wondering what's the best way to do it.


If people have some experience with Splice9 and want to make it 
available with vim at some point, I'm not adverse to it. But I think 
it's a bit premature...


-ernie



I would be interested into trying this out,
There's a video accessible through steve's website that shows how to use 
the tool, as well as configuring git/mercurial/others to use it. Once 
vim9 is stable (any day now)...

  as I have had to fix a few
conflicts already, but I just used the git mergetool -t vimdiff (which
worked surprisingly well, once one knows what all those different files
are)

Best,
Christian



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/d139cb39-48b7-c8c0-6657-dc191ffb5484%40raelity.com.

Splice9 merge tool

[Ernie Rael]

Greetings,

In March of 2022 I started porting Splice[1], a 3 way merge tool written in
vim/python, to vim9script. I had never used vimscript and felt weak when 
it came

to merging; so "two birds with one stone". There's now a pure vim9script
version. It has some UI enhancements.

I'm looking for suggestions/recommendations on setting it up for general
availability. Currently I've got everything under
~/pack/random-packages/start/splice-vim with one file in .../plugin and
everything else under .../autoload/splice9. All imports are relative to
facilitate having multiple versions installed.

I think using autoload for everything was a mistake and caused some of 
the weird
errors I see when screwing around what get's imported and/or what get 
declared
with proper type. In particular if in some file a variable gets exported 
and the
file does imports, autoload can run into problems; now that Splice9 is 
stable,
I'll play around with it. I'm guessing the right thing to do is put app 
files

under import and "library" type files under autoload.

Splice9 is never, well, hardly ever, run from the command line. It it 
run by the
version control tool. Currently I can have .../autoload/splice9 be a 
symlink to
my VCS work area, very simple. But for general use I know there are a 
variety of
ways to provide it, packadd and package managers, and I see this 
EditorConfig

plugin that's now shipping with vim and I wonder if that's relevant, and
possibly a myriad of other approaches.

Anyway, suggestions and/or pointer to docs in this area that discuss best
practices appreciated.

Some of the Splice9 UI enhancements:
    - Additional status info (compact) in the HUD (Heads Up Display).
    - The action buttons in the HUD are clickable.
    - Rollover highlight for active HUD buttons.
    - Click for popup of shortcuts.
    - Can specify each action's ":map"/shortcut individually.
    - Can set "use meta" and the meta key is used instead of using 
g:mapleader.

    - Version control system configuration the same as original Splice.

[1] https://docs.stevelosh.com/splice.vim/

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/c0297c3c-e17c-b455-3e5b-c957b6049149%40raelity.com.

Re: Support for Private class/object methods

[Ernie Rael]

On 23/08/25 2:07 PM, bfrg wrote:
If "public" is omitted, shouldn't class members and method be private 
by default just like "def" functions and script variables are 
script-local by default unless prefixed with "export"?


In general, I would also like it to be symmetric. So, either 
introducing "public" and "private" together, or no modifier keyword at 
all.


Any opinion/comment on "read-only" access in favor of adding Getters?

Would "export" be better than "public" in class definitions?

In the latter case an underscore indicates private class members and 
methods whereas public ones don't have an underscore.


And another issue: why isn't this thread shown in GitHub Discussions? 
Wasn't the whole point of enabling Discussions so that more people can 
participate in such decision making?

On Friday, August 25, 2023 at 6:11:34 AM UTC+2 Doug Kearns wrote:

On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan
 wrote:

Hi all,

The following item is in the todo.txt file for implementing
private
methods in a class:

 - Private methods?
        either: private def Func()
            or: def _Func()
    Perhaps use "private" keyword instead of "_" prefix?

Function and method names always start with an uppercase
letter.  So
if we use the
"_" prefix for a private method name then it will diverge from
that. So I have
implemented this using the "private" keyword.

Any opinions?


Thanks very much for keeping the ball rolling on this.

For others, there was some previous discussion[1] about it on the
list when Bram asked for opinions.  My recollection is that both
you and he were in favour of the "_" prefix for call-site
identification purposes?

My personal preference would be for the modifier keyword with a
symmetric, even if possibly redundant, "public".  I think this is
justifiable on the grounds of it meeting the "less weird"
requirement for Vim9 script.  While I'm sure there are others,
JavaScript is the only language I can think of off the top of my
head that defaults to public and uses a sigil for private access.

Thanks again,
Doug

1.
https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/394f9be0-0aef-4c32-9da0-a90ac499723fn%40googlegroups.com 
.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/b004fd8a-8246-0e6d-5e79-e16943f6c2ad%40raelity.com.

Re: Vim9: Default object member access

[Ernie Rael]

On 23/08/25 6:50 AM, Yegappan Lakshmanan wrote:

Hi all,

>From the email thread
https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1
and the following items in the todo.txt file:

   - Change access: public by default, private by prefixing "_".
 Check for error: can't have the same name twice (ignoring "_" prefix).

This is not yet implemented.  We cannot change this after releasing Vim 9.1.
Should we make this change now?


Default read-only is my preference; more precisely /not default public/. 
(Hasn't changed since that thread was active.) Having worked with 
vim9class, I don't feel as strongly about it as I did at the beginning 
of the year; but considering how expensive function calls are, having a 
read-only mechanism is not only a safety advantage.


Error if both "_foo" and "foo"; strongly think there should be an error.

The only comment I saw from Bram in the thread specifically about 
default /public/ versus /read-only/ has to do with *simple* versus 
*safe*. From the thread, in response to a suggestion that public should 
be the default:


   About public/private/read-only: Making the default public is certainly
   possible. I think most languages have it that way, even though it's not
   a safe choice.

   I do like the read-only access. Quite often you want to disallow any
   code outside of the class to change a member, so that you can make sure
   the value is valid. But making it private means you have add a
   "getter" and call it. [...]

   Nevertheless, if we give priority to keeping it simple, making members
   public by default and using the underscore for private is the way to go.


I was aghast (well, maybe just surprised) to see that

   vim9script

   class C
    this._foo: number
    this.foo: number
    def Dump()
    echo this._foo this.foo
    enddef
   endclass

   C.new(3, 5).Dump()

works. I agree with this comment from the thread about allowing both 
"_foo" and "foo"


   No, we should not allow that, it is not only confusing, it also
   makes it
   difficult to change a member from private to public later.

-ernie



Thanks,
Yegappan



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/96d874d0-a3fb-eeeb-6c35-fb5b739e4c39%40raelity.com.

Re: Support for Private class/object methods

[Ernie Rael]

On 23/08/24 9:22 PM, shane.qian wrote:

On 23/08/24 08:18PM, Yegappan Lakshmanan wrote:

Hi all,

The following item is in the todo.txt file for implementing private
methods in a class:

  - Private methods?
 either: private def Func()
 or: def _Func()
 Perhaps use "private" keyword instead of "_" prefix?

Function and method names always start with an uppercase letter.  So
if we use the
"_" prefix for a private method name then it will diverge from that. So I have
implemented this using the "private" keyword.

Any opinions?

Thanks,
Yegappan

what's the time that 'todo' item added?
2022/02/08 bram had comment about that:
https://github.com/vim/vim/issues/9713#issuecomment-1031938822


Note that the 'todo' item is about class methods, not functions in 
general. The discussion where Bram brought up the question is January of 
2023.


-ernie





--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/433cd70a-44cf-1ffd-bfb1-32483a002701%40raelity.com.

Re: Support for Private class/object methods

[Ernie Rael]

On 23/08/24 9:10 PM, Doug Kearns wrote:
On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan 
 wrote:


Hi all,

The following item is in the todo.txt file for implementing private
methods in a class:

 - Private methods?
        either: private def Func()
            or: def _Func()
    Perhaps use "private" keyword instead of "_" prefix?

Function and method names always start with an uppercase letter.  So
if we use the
"_" prefix for a private method name then it will diverge from
that. So I have
implemented this using the "private" keyword.

Any opinions?


Thanks very much for keeping the ball rolling on this.

For others, there was some previous discussion[1] about it on the list 
when Bram asked for opinions.  My recollection is that both you and he 
were in favour of the "_" prefix for call-site identification purposes?


My personal preference would be for the modifier keyword with a 
symmetric, even if possibly redundant, "public".


Is it only redundant, or is there some semantic meaning or change? 
Referring only to functions?


About that "_". Looking through that old thread, and thinking about the 
code I've got. It is convenient to look at a member name and immediately 
know it's private. Allowing "private" doesn't seem that important; I 
don't particularly buy into the "only have one way to do it" but private 
member seems low priority to me.


-ernie


I think this is justifiable on the grounds of it meeting the "less 
weird" requirement for Vim9 script.  While I'm sure there are others, 
JavaScript is the only language I can think of off the top of my head 
that defaults to public and uses a sigil for private access.


Thanks again,
Doug

1. https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAJ1uvoBnoV9pM47k%2BGsSDApk3Xciu4RgGrSQJKbc0V1e8NAJjw%40mail.gmail.com 
.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/3981d25d-d088-800d-462e-106f7be031fb%40raelity.com.

Re: Support for Private class/object methods

[Ernie Rael]

On 23/08/24 8:18 PM, Yegappan Lakshmanan wrote:

Hi all,

The following item is in the todo.txt file for implementing private
methods in a class:

  - Private methods?
 either: private def Func()
 or: def _Func()
 Perhaps use "private" keyword instead of "_" prefix?

Function and method names always start with an uppercase letter.  So
if we use the
"_" prefix for a private method name then it will diverge from that.

That's mostly a parsing issue? The requirement becomes _[A-Z] means private.

  So I have
implemented this using the "private" keyword.

Can "private" be used with members, in addition to prefixing "_"?

Any opinions?
I'm personally OK with "private", and happy to avoid the parsing 
hassles. Would like to see it usable with class/instance members.


-ernie



Thanks,
Yegappan



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/969ed3c5-c760-e743-d057-3b48f1f10b85%40raelity.com.

Re: Updates on the Vim project

[Ernie Rael]

On 23/08/24 2:44 AM, Tony Mechelynck wrote:

[...]
Well,  if the Mercurial mirror goes puff, I'll have to decide
either to fall back on the Vim from my distro (always somewhat behind,
currently 9.0.1632 and with a slightly different choice of features
than I would have chosen) or to start learning git seriously on a
fresh clone.


Have you considered the "hg-git" extension? "hg-git" on PyPi. It's had a 
lot of work done in the last couple of years; it's in good shape,  with 
regular releases. Also the newer "evolve" extension is useful, I use it 
in favor of mq.


-ernie



Best regards,
Tony



Let me know, what you all think.
__
¹) https://github.com/vim/vim/pulls?q=is%3Aopen+is%3Apr+milestone%3Avim-9.1

Thanks,
Christian
--
You are dishonest, but never to the point of hurting a friend.

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ZOZpf40nvrjjllpo%40256bit.org.



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/8ee16bd0-86f5-f70e-10e3-1decc99cdbd0%40raelity.com.

Re: Updates on the Vim project

[Ernie Rael]

Hoping https://github.com/vim/vim/pull/12192 is merged.

Vim 9.1 has a nsec profiling clock available; but without this PR, which 
fixes a severe timing problem related to user function calls, we can't 
say v9.1 has high accuracy profiling.


-ernie

On 23/08/23 1:18 PM, Christian Brabandt wrote:

Hi,
this is a small update over what happened the last few weeks.

Over the last days, I have been merging mostly runtime file changes,
small improvements to the Vim9 class implementations and bug fixes.

If you check the Milestone¹ for the release 9.1, most of the remaining
changes are small runtime changes, for which I'd like to get an
ACK/NACK.

Thanks for all your contributions, this is really appreciated!

I am not sure, what the status of the Vim9 classes implementation is and
if we are going to get further improvements there or if we can consider
this "good enough".

@Yegappan, what is your opinion?

If you are a runtime file maintainer, or you have been providing
translations, now it's time to check your runtime files against the
version in the Vim repository and please consider sending updated files.

I also checked the huntr organization, but it looks like there are no
open security issues reported over there.

On a somewhat related note, I have been asked how to handle security
issues in the future and I am thinking about creating a "private" list
for this. Not sure how to handle packagers or if it is good enough, if I
mark commits/mails with some security related flag.

Regarding the vim Homepage, I'll move it to a new hoster after the
release has been done. I got several offers so that should not be a
problem.  I'll also need to check the amount of work to migrate the old
php5 code to an updated php version.

Regarding the ftp server, I decided to no longer use it. I checked with
the owners and while they were willing to help, I come to the conclusion
that it stems from an old time and it no longer required, so I will not
update the data there.  I may however need to download the generated
spell files and move this to the new Vim Homepage, once it has been
moved.

For a similar reason and because of the mess I created with the
mercurial mirror, I am thinking to retire the mercurial repository. I
think it is pretty clear that nowadays git is the preferred VCS of
choice for most programmers.

Let me know, what you all think.
__
¹) https://github.com/vim/vim/pulls?q=is%3Aopen+is%3Apr+milestone%3Avim-9.1

Thanks,
Christian



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/63580a31-2f0c-74c7-1e8f-43a69efe10ab%40raelity.com.

Re: the git-hg bridge

[Ernie Rael]

On 23/08/23 12:14 PM, Tony Brown wrote:

Why are you still using mercurial?


I dont' want to start yet another flame war on this topic (though I 
wouldn't mind, considering how I feel about git).


I use mercurial's hggit extension and find it interoperates fine with 
github. I used the mercurial bridge starting when it was first 
available, then about a year ago switch to using hggit directly to the 
main vim github repository. I seem to remember that with the bridge 
there were two log entries per patch, but using hggit there was only one.


-ernie




On Wed, Aug 23, 2023 at 2:02 PM Christian Brabandt 
 wrote:


Hi,
currently I am experiencing some problems with the git-mercurial
bridge.

I don't know exactly what is going on, but it seems, mercurial
does not
like patches generated by git anymore and aborts imported patches.
This
seems to happen quite often with updated translations.

Not sure, why it starts failing now, since this used to work for
years.

Apologize for this situation and the messy hg logs :(

Thanks,
Christian
-- 
Your fly might be open (but don't check it just now).


-- 
-- 
You received this message from the "vim_dev" maillist.

Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to vim_dev+unsubscr...@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/ZOZI3CORY5PkfbPC%40256bit.org.

--
Sent from Gmail Mobile
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CAAmO4oMJqg2D6pO5M0D3eWw8DXGdeSTH5kE-KPooU1SNhupNHA%40mail.gmail.com 
.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/7b04dff9-59b9-c70d-6e36-dbf0b8152ba2%40raelity.com.

Re: actual error

[Ernie Rael]

Related, perhaps off topic.

I was doing "hg bisect" a few days ago, the pass/fail detection had to 
build vim and run a test. The process aborted after several iterations 
because of a writable source file and the working directory couldn't be 
updated. (I made notes, but lost them in the heat of battle)


There were two artifacts when bisect aborted. One was something very 
much like


   M src/po/ja.sjis.po

The other was an untracked file with the same, or very similar, name; maybe at 
a different level in the tree.

I fixed the problem by add "hg revert" after building, so the bisect rev update 
wouldn't abort. Probably changed other stuff as well. I think I've seen this source tree 
file as writable before, sometime within the last few weeks.


-ernie

On 23/08/20 1:34 AM, Christian Brabandt wrote:

On Sa, 19 Aug 2023, tooth pik wrote:


Unstaged changes after reset:
M src/po/ja.sjis.po
M src/po/zh_CN.cp936.po
M src/po/zh_CN.po

error: Your local changes to the following files would be overwritten by merge:
src/po/ja.sjis.po
src/po/zh_CN.cp936.po
src/po/zh_CN.po
Please commit your changes or stash them before you merge.
Aborting
Updating 56bafd7a6..4b1cc7906

Not sure what you are trying to say here. You need to get rid of the
changes to your local files before you can update them. So that's why I
suggested to use git reset --hard. Note this will wipe out all your
changes. So only do this if you don't care about it. Other options would
be to use git stash for example, that would stash away your changes (and
you could get them later back).

Best,
Christian


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/de026c02-a065-647e-956a-43a5e7ed2341%40raelity.com.

vim9class, getting it usable

[Ernie Rael]

Hi all,

Working on a project Feb/Mar using vim9 classes I filed several issues. 
Each time found a workaround, and went on. Finally ran into


   https://github.com/vim/vim/issues/12089
   vim9class: Calling a base class method through an extending class
   fails #12089

   Also included "Calling a method in an extended class fails" (fixed a
   few days ago)

Put the project back on the shelf, didn't make sense to go on without 
inheritance. I wonder if it's worth doing 9.1 if classes (inheritance) 
doesn't work.


Took a quick look at the code in Apr/May, but seemed like too much to 
take on at the time. Thinking again about moving forward, however 
slowly, the first thing I thought to do is add some debug commands to 
vim that would dump class and hierarchy information; adding to the 
commands as more information was needed. Even the basic structure isn't 
clear to me and how it evolves to compilation/run-time. The examples in 
the issue referenced above work at script level, fail in a :def. Does 
this mean the basic class hierarchy structures are interpreted from 
script and then combined into some structures that are used by the 
compiler, are the structures also used during runtime. Anyway, I was 
encourages to see @yegappan get some things fixed in this area.


I'm not sure how I can best contribute (or, as goes without saying, how 
much time I'll have). The biggest problem is it looks like a steep 
learning curve. Looking for any suggestions on getting up to speed 
enough to contribute.


-ernie

PS I went with here, rather than discussion. Right choice?

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/51d7532a-be77-2861-1798-f82ef382539a%40raelity.com.

Surprising test failure after rebasing PR

[Ernie Rael]

Bunch of failures, all of them

   Set up snd-dummy
   E: Package 'linux-modules-extra-5.15.0-1042-azure' has no
   installation candidate

I see this after rebasing and pushing two PR's.

Is there something I need to do?

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ca7afb2c-5a0e-ea25-6b19-ce18fe84fb29%40raelity.com.

Re: test_codestyle failure

[Ernie Rael]

On 23/06/03 11:30 PM, Christ van Willegen wrote:

Hi,

Op zo 4 jun. 2023 02:25 schreef Ernie Rael :

Earlier today I rebased and pushed a couple patches that were last
pushed around a month ago (cleanly). Getting lots of test failures
as shown below. Is there something I need to fix?

-ernie

Failures:
From test_codestyle.vim:
Found errors in Test_source_files():
command line..script
/home/runner/work/vim/vim/src/testdir/runtest.vim[569]..function
RunTheTest[52]..Test_source_files line 40: ../evalfunc.c: missing
white space after "if"/"while"/"for": Expected 0 but got 642
command line..script
/home/runner/work/vim/vim/src/testdir/runtest.vim[569]..function
RunTheTest[52]..Test_source_files line 40: ../list.c: missing
white space after "if"/"while"/"for": Expected 0 but got 2340


Check line 642 in evalfunc.c and line 2340 in list.c


Doh! I psyched myself out. Given that it used to be OK, when I saw the 
"Expected 0", I thought it was a count.


Thanks,
-ernie



You'll need to add a space before the (, probably...

Christ van Willegen

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/CA%2BOt1Oyd3n5TrrK2pB854FYRQpSXhi7EvrfYFv50%2Bk0czjJ9iQ%40mail.gmail.com 
<https://groups.google.com/d/msgid/vim_dev/CA%2BOt1Oyd3n5TrrK2pB854FYRQpSXhi7EvrfYFv50%2Bk0czjJ9iQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/59a5af3a-54ea-145b-403a-db6de369b6b1%40raelity.com.

test_codestyle failure

[Ernie Rael]

Earlier today I rebased and pushed a couple patches that were last 
pushed around a month ago (cleanly). Getting lots of test failures as 
shown below. Is there something I need to fix?


-ernie

Failures:
From test_codestyle.vim:
Found errors in Test_source_files():
command line..script 
/home/runner/work/vim/vim/src/testdir/runtest.vim[569]..function 
RunTheTest[52]..Test_source_files line 40: ../evalfunc.c: missing white 
space after "if"/"while"/"for": Expected 0 but got 642
command line..script 
/home/runner/work/vim/vim/src/testdir/runtest.vim[569]..function 
RunTheTest[52]..Test_source_files line 40: ../list.c: missing white 
space after "if"/"while"/"for": Expected 0 but got 2340


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ff14b506-fc1a-39cc-11de-d67e5726a77c%40raelity.com.

Re: "var F = obj.classMethod" What type is F?

[Ernie Rael]

And there might be additional functionality, e.g. to get the
object that has been bound to.

I was wondering about getting the object. If you can get the object, is is
possible to set the object? If there is something like
      setboundobject(bound-object-method, object)

I don't think so.  It sounds like a corner case, not much practical use.
You can get the dict from a partial with get().  You can change it with
function(), but there is no type checking at all.  When using an object
instead of a dict type checking would be very relevant.


I agree, and I don't see it as a problem at all; it's easy to get the
functionality. Consider the following

    var methodNameAsVar(obj: BaseType, ...args: any) => {
    call(obj.methodName, args)
    }

    methodNameAsVar(obj, arg1, arg2)

With possible runtime errors.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6d6691b5-cefa-4f09-f29b-7b272efa27b7%40raelity.com.

Re: "var F = obj.classMethod" What type is F?

[Ernie Rael]

On 23/05/21 4:49 AM, Bram Moolenaar wrote:

Ernie Rael wrote:


  > > var F: func = obj.classMethod
  > 1. Binding an object with an object method, like a dictionary is bound
  > to a function on a dictionary. "obj.classMethod" in the example.
  >
  > This applies to 1: It will be a new type, as the bound object is
  > included, which differs from a function that is not bound.

Seems like making it a new type is more work for no benefit.
There's the vim9script programmers view, and the vim internals view.

It's often not possible to hide the internal view from what users
experience.  We do have incomplete types, such as "any" or "func", which
require runtime type checking.  That means you don't get errors for
wrong usage during compile time.  And at runtime you might get a
different error depending on what type of function is being passed
around.

My primary concern is that a bound-object-method can be used anywhere a
func can be used. Passing it to an existing function that has an argument
declared "arg: func" or to a builtin that expects a funcref. I have one
case that might push the limit

    export def Log(msgOrFunc: any, category: string = '')
    var msg_type = type(msgOrFunc)
    ...
    elseif msg_type == v:t_func


And there might be additional functionality, e.g. to get the
object that has been bound to.

I was wondering about getting the object. If you can get the object, is is
possible to set the object? If there is something like
    setboundobject(bound-object-method, object)
and if the type of object must be assignable to the original object type,
then you you have a variable which is similar to a c++ "pointer to a member
function" except that it includes the object. This would seem to satisfy
the clamoring for using a method as a value. I guess the object could be
any arbitrary type, but that feels much more complicated.


If you mean, whether the type declaration needs to be different, I'm not
sure.  Currently a partial isn't declared differently from a function
reference, it might be possible to not have a separate type declaration
when an object is bound to a function.  But since the functionality is
different, it might be useful to declare the type in a way that makes
clear this functionality is available.

Is type being used imprecisely? (Like declare versus define)
I can see defining a bound object method differently
    var F: func
    F = bindobjectmethod(obj, method)
which wouldn't affect any existing code. But if the resulting type
is not t_func that presents compatibility/usage problems.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5e24f842-e126-412c-3ff2-076956f790b1%40raelity.com.

Re: Failure using "g:" as a dict

[Ernie Rael]

On 23/03/31 11:33 AM, Bram Moolenaar wrote:

Doing

 vim -c 'vim9cmd g:["my-output-dir"] = "vglob-dir"'

give this error

 Error detected while processing command line:
 E461: Illegal variable name: my-output-dir

Turns out

 vim9script
 g:["foo-bar"] = "baz"

also fails.

Both errors are intended: You cannot use a dash in a variable name.


OK. So "g:" can be treated as a dictionary as a convenience.
It's not really a dictionary.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/18bd1edf-f0f4-75c0-7653-22f2748e3905%40raelity.com.

Re: using vim to run vim9script

[Ernie Rael]

On 23/03/29 5:42 PM, Tony Mechelynck wrote:

On Wed, Mar 29, 2023 at 9:58 PM Ernie Rael  wrote:
[...]

The interesting thing is that if the vimscript
exits with an exception or :cquit, then after the bash shell
script exits, the return code is 1 (as hoped for), otherwise it
exits with 0. This seems to be undocumented behavior.

[...]
It is documented under ":help :cquit" — I looked for behaviour on :qa
with an uncaught exception but didn't find anything. Maybe that's what
":h v:exiting" covers.
Also, :cquit 5 or :5cquit makes Vim exit with return code 5 (or
similarly for other values). I think that in such a case the bash
script would exit with the return code of the last command it ran but
I'm not 100% sure (another possibility would be 1 for false, 0 for
true, nothing else).

Best regards,
Tony.


Thanks Tony,

Didn't know about v:exiting, and I think I've only used an autocmd
once (in an app I'm porting to vim9).

I'm getting good behavior. I generally want this stuff to run quietly,
and the most important thing is to have error information show up and
be able to detect problems from the exit status. When I first started
looking at this I think I confused myself by thinking that somehow
vim's "source" command was independent, something like unix fork().
Also when the sourced script got an exception, the "queued" commands
like "-c q" still got executed. After I cleared my head, there is only
one vim process in play (even if it's called "ex"), things make sense.

I've run into some quirky behavior, see below; but I have quirky
behavior; so so what. The first two are my typical use case. I tried a
few things with :cquit; in the 3rd example, somewhere it seems to be
adding one to the cquit argument if there's been an exception.

t.bash sets up things and does: =
ex -s \
    -c "redir >> /dev/stdout" \
    -c "source $vimscript" \
    -c "echo 'ex quitting'" \
    -c q
rc=$?
echo
exit $rc

-1- =
=== Started with 'ex -s -c "source $vimscript"' in t.bash ===
vim9script
autocmd VimLeave * echo "vim exiting:" v:exiting v:dying
echo 'DONE'
= console =
$ ./t.bash

DONE
ex quitting
vim exiting: 0 0
err@harmony:~/experiment/vim/vimprofiling
$ echo $?
0

-2- =
=== Started with 'ex -s -c "source $vimscript"' in t.bash ===
vim9script
autocmd VimLeave * echo "vim exiting:" v:exiting v:dying
throw "FORCE EXIT"
= console =
$ ./t.bash

Error detected while processing command line..script ...
line    4:
E605: Exception not caught: FORCE EXIT
ex quitting
vim exiting: 1 0
err@harmony:~/experiment/vim/vimprofiling
$ echo $?
1

-3- =
=== Started with 'ex -s -c "source $vimscript"' in t.bash ===
vim9script
autocmd VimLeave * echo "vim exiting:" v:exiting v:dying
autocmd VimLeave * cquit 7
throw "FORCE EXIT"
= console =
$ ./t.bash

Error detected while processing command line..script ...
line    4:
E605: Exception not caught: FORCE EXIT
ex quitting
vim exiting: 1 0
err@harmony:~/experiment/vim/vimprofiling
$ echo $?
8

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/eae44b94-d8dd-a713-42da-f819af730510%40raelity.com.

Re: using vim to run vim9script

[Ernie Rael]

Wrapping the invocation of "ex -s ..." seems to work pretty well;
args can be processed by the wrapper script, passed to vim as globals.

In the following test, note the final "-c q", it is needed to prevent
vim waiting in exmode. The interesting thing is that if the vimscript
exits with an exception or :cquit, then after the bash shell
script exits, the return code is 1 (as hoped for), otherwise it
exits with 0. This seems to be undocumented behavior.

The only weirdness is that the last echo of the vimscript
does not have a trailing newline, but that's remedied
with an echo in the bash script.

   ex -s -c "$arg" \
    -c "redir >> /dev/stdout" \
    -c "source $vimscript" \
        -c q
   echo

-ernie



On 23/03/28 12:15 PM, Ernie Rael wrote:


I want to run some vim stuff from a shell script.

Some issues I can think of

  * passing arguments to vim
  * don't draw a screen
  * seeing output
  * seeing errors

The following more or less works; it would be nice
if vim, on an error, automatically exited with an error;
"echo g:what" in this case.

Looking for suggestions and/or alternatives and/or doc ref?

Thanks,
-ernie

Doing:

ex -s -c 'let g:arg = 123' -c 'redir >> /dev/stdout' -c 'source t.vim'

where t.vim is

vim9script
echo g:arg
echo 'foo'
echo g:what
echo "\n"
q

produces the output

123
foo
Error detected while processing command line..script /.../t.vim:
line    4:
E121: Undefined variable: g:what
Entering Ex mode.  Type "visual" to go to Normal mode.



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6443a0af-f327-43ec-b6ee-49f855466fe7%40raelity.com 
<https://groups.google.com/d/msgid/vim_dev/6443a0af-f327-43ec-b6ee-49f855466fe7%40raelity.com?utm_medium=email&utm_source=footer>.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/7f360287-0059-dfe3-ed6f-3f17967e37de%40raelity.com.

Failure using "g:" as a dict

[Ernie Rael]

Doing

   vim -c 'vim9cmd g:["my-output-dir"] = "vglob-dir"'

give this error

   Error detected while processing command line:
   E461: Illegal variable name: my-output-dir

Turns out

   vim9script
   g:["foo-bar"] = "baz"

also fails.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/9764aaf4-fb0e-f718-7955-4dac257d83a9%40raelity.com.

using vim to run vim9script

[Ernie Rael]

I want to run some vim stuff from a shell script.

Some issues I can think of

 * passing arguments to vim
 * don't draw a screen
 * seeing output
 * seeing errors

The following more or less works; it would be nice
if vim, on an error, automatically exited with an error;
"echo g:what" in this case.

Looking for suggestions and/or alternatives and/or doc ref?

Thanks,
-ernie

Doing:

   ex -s -c 'let g:arg = 123' -c 'redir >> /dev/stdout' -c 'source t.vim'

where t.vim is

   vim9script
   echo g:arg
   echo 'foo'
   echo g:what
   echo "\n"
   q

produces the output

   123
   foo
   Error detected while processing command line..script /.../t.vim:
   line    4:
   E121: Undefined variable: g:what
   Entering Ex mode.  Type "visual" to go to Normal mode.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6443a0af-f327-43ec-b6ee-49f855466fe7%40raelity.com.

Makefile/compiling

[Ernie Rael]

(BTW: Minor bug in Makefile comment about getting "-O -g" by default.)

I'm curious about the "best" way to compile vim. For example,
can I crank up the optimization to extreme levels?

-ernie

In the Makefile it has

   # When not defined, configure will try to use -O2 -g for gcc and -O
   for cc.
   #CFLAGS = -g
   #CFLAGS = -O

I've added, and put in a prefix ="

   +CONF_OPT_GUI = --enable-gui=gtk3
   +CONF_OPT_PYTHON3 = --enable-python3interp

Did "make reconfig" gcc is used and the options are

   -O2 -fno-strength-reduce -Wall -Wno-deprecated-declarations

No "-g", like having it just in case a core shows up. (Use -g -O0 for 
debugging).


   gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0

I can't find any doc for "-fno-strength-reduce".
Is it historical or for some other compiler?

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/2b95eccd-1b9a-a003-04ea-b1f3a0cf3d4c%40raelity.com.

Re: map() slows down dramatically after vim running a while

[Ernie Rael]

On 23/03/24 10:45 AM, Bram Moolenaar wrote:

You might want to store the hash number with the function to avoid the
overhead of computing it.

This still needs to be done. To make sure I understand,
this is saving `hash_hash(name)` in ufunc_T and has_profiling has an
additional argument which is the hash. And if this argument is zero
then the hash would be computed in has_profiling.

I haven't looked at the PR yet, but I would think that as soon as you
have the function pointer, you can use the field that has the hash
value.  It is based on the function name, which doesn't change.  Thus it
needs to be computed only once.
Right, that's what I meant . After thinking about it a bit more, I went 
ahead and
implemented something, and pushed it last night, as you'll see. Caching 
the hash

is an easily detected improvement.

-ernie



However, if you mean the hash value of the pattern, then it would be
stored in "struct debuggy".  Obviously it depends on what key you use
for the hash table.



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/af7cbe90-fcbf-83ec-1a70-fe58dc9c076a%40raelity.com.

Re: map() slows down dramatically after vim running a while

[Ernie Rael]

FYI, back to where the latest profiler work started (after nsec clock)

The goal: compare performance "map(in, 'v:val')" vs "map(in, Map1)". Map1 is
    def Map1(_, val: number): number
    return val
    enddef
Turns out for processing a list with 3 items, 1.049 usec vs 1.590 usec;
at least that's the current results. (And not 1.166 vs 103)

Current vim:
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
  0.608  0.625  0.641  0.999  0.957  0.954  1.237  1.179  1.166 : 
map(in, 'v:val')   ###-2
  0.068  0.072  0.071  0.071  0.068  0.069  0.070  0.070  0.070 : 
result = []   ###-4
  0.144  0.151  0.146  0.171  0.166  0.164  0.194  0.190  0.189 : in = 
input->copy()   ###-5
  2.784  6.023 10.140 27.808 36.471 45.324 77.819 92    103 : 
map(in, Map1)   ###-6


Upgraded function profiling patch
  0.599  0.574  0.568  0.902  0.795  0.807  1.121  1.066  1.049 : 
map(in, 'v:val')   ###-2
  0.071  0.072  0.071  0.072  0.069  0.071  0.071  0.070  0.070 : 
result = []   ###-4
  0.152  0.151  0.149  0.179  0.175  0.173  0.200  0.200  0.205 : in = 
input->copy()   ###-5
  0.807  0.771  0.723  1.179  1.182  1.165  1.663  1.598  1.590 : 
map(in, Map1)   ###-6


-ernie

On 23/03/23 7:31 PM, Ernie Rael wrote:

Opened draft PR: https://github.com/vim/vim/pull/12192
Initial results are promising, one measure is how few loops are
required for the results to stabilize.
And the results show *faster times* when user defined functions
are involved. It's interesting how good that feels, even though
it doesn't mean anything is actually running faster in production.

On 23/03/23 8:19 AM, Bram Moolenaar wrote:

Ernie Rael wrote:

You might want to store the hash number with the function to avoid the
overhead of computing it.


This still needs to be done. To make sure I understand,
this is saving `hash_hash(name)` in ufunc_T and has_profiling has an
additional argument which is the hash. And if this argument is zero
then the hash would be computed in has_profiling.


   The overhead of looking up the key in the
table can't be avoided.  Also, when more function names are being cached
updating the hash table can also take a noticable amount of time.
Yes, but it also would usually indicate that the table has been very 
useful.


I don't know most use cases; does the number of things being profiled
change dynamically or very often?

-ernie
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/911e2e0b-ab7b-8d34-e205-6c6cbeea1cc8%40raelity.com 
<https://groups.google.com/d/msgid/vim_dev/911e2e0b-ab7b-8d34-e205-6c6cbeea1cc8%40raelity.com?utm_medium=email&utm_source=footer>.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/f61e3ca8-180e-85c7-b050-24a7f7203b6d%40raelity.com.

Re: map() slows down dramatically after vim running a while

[Ernie Rael]

Opened draft PR: https://github.com/vim/vim/pull/12192
Initial results are promising, one measure is how few loops are
required for the results to stabilize.
And the results show *faster times* when user defined functions
are involved. It's interesting how good that feels, even though
it doesn't mean anything is actually running faster in production.

On 23/03/23 8:19 AM, Bram Moolenaar wrote:

Ernie Rael wrote:

You might want to store the hash number with the function to avoid the
overhead of computing it.


This still needs to be done. To make sure I understand,
this is saving `hash_hash(name)` in ufunc_T and has_profiling has an
additional argument which is the hash. And if this argument is zero
then the hash would be computed in has_profiling.


   The overhead of looking up the key in the
table can't be avoided.  Also, when more function names are being cached
updating the hash table can also take a noticable amount of time.

Yes, but it also would usually indicate that the table has been very useful.

I don't know most use cases; does the number of things being profiled
change dynamically or very often?

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/911e2e0b-ab7b-8d34-e205-6c6cbeea1cc8%40raelity.com.

Re: map() slows down dramatically after vim running a while

[Ernie Rael]

On 23/03/22 3:02 PM, Bram Moolenaar wrote:

Ernie Rael wrote:


Poking around...

In debugger.c::debuggy_find():976 it looks like there's a missing `break;`.

Hmm, it needs to loop if "lnum" can be lower in another entry, but for
profiling that doesn't matter.  I suppose we could break when
"gap == &prof_ga".  Do you want to make a PR for that?



Will do.


With my corrected code, has profiling() still looks like ~11% of the the
time (it's got those two vim_regexec...()); wonder if has_profiling()
could/should cache the results of debuggy_find().

Caching can be tricky.  In this case it can be difficult to clear cached
information when anything changes (new function defined, profiling entry
added/deleted, etc.).

We're caching the result of running regexp on a name (I think); I don't see
how adding a function changes that. I'm thinking of something like

    has_profiling(...)
    {
    result = table->get(fname, null);
    if (result == null)
    {
    result = debuggy_find(...);
    table[fname] = result;
    }
    return result;  // handle direct return and optional forceit
    }

The table is cleared whenever prof_ga is modified. Should be easy to
detect since prof_ga is static in debugger.c.

I was thinking of two tables, for file and function, and avoid constructing
keys that distinguish the cases.

A potential problem is "forceit", I'm not sure what this is about and
whether or not it can be cached. If it can be cached, the a value in the
table is two bits, has_profile and forceit (assuming foreit is boolean).

I'm also assuming that the main if condition is always true for
has_profile; "bp->dbg_type == DBG_EXPR" is never true.

Any simple examples of using hashtable in "C" that I can reference?



is it worth it?


Some uniform degradation, while undesirable, is not unexpected when
profiling. The problem here is the degradation in results is not uniform
and is large in some cases; it is due to the regex engine and the order of
stuff in a table that's used by the profiler. Can vary while running.

In this case, `map(in, Map1)`, the map builtin invokes a user defined
function; I'm guessing on invocation of that function the profiler looks it
up. The lookup takes a seemingly arbitrary amount of time and counts it
against the `map`. I've seen results 50x slower for the `map`; while lines
that do not involve a user function are not affected.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/9704325e-60b4-ae3b-7735-e75e4861a612%40raelity.com.

Re: map() slows down dramatically after vim running a while

[Ernie Rael]

Poking around...

In debugger.c::debuggy_find():976 it looks like there's a missing `break;`.

With my corrected code, has profiling() still looks like ~11% of the the 
time (it's got

those two vim_regexec...()); wonder if has_profiling() could/should cache
the results of debuggy_find().

-ernie

On 23/03/22 10:48 AM, Ernie Rael wrote:


On 23/03/20 10:56 PM, Ernie Rael wrote:
It is the profiling itself that is causing the results to be so 
skewed as

things run longer. I guess the thing to do now is use the linux/gnu
profiler to profile the vim profiler.



Found it.

Doing
    execute 'profile func' funcref(Func)->get('name')
    profile start xxx.profile.out
generates
    Error detected while processing command line..script 
/home/err/play/xxx.vim:

    line   15:
    E750: First use ":profile start {fname}"
I assumed (bad programmer) that the list of functions to profile is
cleared by `profile stop`; after all you can't set the functions
without doing `profile start`.

So I've been doing
    profile start xxx.profile.out
    execute 'profile func' funcref(Func)->get('name')
    Func()
    profile stop
and this gets done multiple times while collecting data.

Here's some gprof output
  %   cumulative   self  self total
 time   seconds   seconds    calls  ms/call  ms/call  name
 31.82  0.07 0.07   542508 0.00 0.00 nfa_regmatch
Without a function name being set multiple times nfa_regmatch
is at most a blip. BTW, the name looks like `47_T`.

This profiling behavior is confusing at best.

Throwing out duplicate patters is a thought.
I wonder if `function name {pattern}` that don't require regexp
could/should be handled without it; maybe a table lookup.

-ernie




During a single run of vim, for the current analysis, 45 profile 
files are

created; the profile structures are torn down and rebuilt 45 times. I've
modified my profiling framework such that all the programs are still 
run,
but the profiler is enabled on a per column basis. In addition the 
output

shows the run order of the various columns.

Only the 3rd and 9th columns are profiled
   1x99   3x99 : nInputXnLoop (cells: usec/op)
 #3 #9 : run order
  0.596  1.177 : map(in, 'v:val')   ###-2
  3.110 17.203 : map(in, Map1)   ###-6

Reverse order
   1x99   3x99 : nInputXnLoop (cells: usec/op)
 #7 #1 : run order
  0.644  1.068 : map(in, 'v:val')   ###-2
  6.113  4.903 : map(in, Map1)   ###-6

All 9 columns are profiled
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
 #1 #2 #3 #4 #5 #6 #7 #8 #9 : run 
order
  0.608  0.592  0.603  0.941  0.954  0.976  1.269  1.217  1.208 : 
map(in, 'v:val')   ###-2
  2.550  5.884 10.559 26.990 36.463 44.996 79.196 90    106 : 
map(in, Map1)   ###-6


All columns profiled in reverse order
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
 #9 #8 #7 #6 #5 #4 #3 #2 #1 : run 
order
  0.789  0.735  0.682  0.975  1.690  0.932  1.209  1.108  1.059 : 
map(in, 'v:val')   ###-2
 34.596 30.699 27.083 50.110 77.150 28.901 31.590 17.570  4.486 : 
map(in, Map1)   ###-6


In the previous results, excepting for the first and last columns, the
order of the column execution was incorrectly stated. The conclusions 
are

the same and the results make more sense now.


On 23/03/20 5:33 PM, Ernie Rael wrote:
Is this expected? All the results/table are collected in a single 
instance

of vim; tried it with "-u NONE". I've run asan and valgrind on
test_filter_map and don't see any leaks. If these results are a 
surprise, I

can look further. I haven't run the linux/gnu profiler yet. I saw vim's
MEM_PROFILE, I'll check that out. Other suggestions for investigation?
Not just map, but that's part of what I'm looking at now.

Looking to understand some profiling results.
In the following nInput is number of items in "input: list"
The code is run 5 times with the specified parameters nInputXnLoop.
Each cell is the fastest result of the 5 runs.

The first set of results are execute left to right, the second set 
are run
right to left. I had incorrectly thought that more work and higher 
number

of loops caused the slower results; but it seems that the greatest
contributor to slowdown is how much vim's been running. The most 
dramatic

difference can be seen
    in 3x99 (list of 3 numbers, 99 loops) for map(in, Map1)
    119 usec/op vs 5 usec/op.
Note that map(in, 'v:val') has a similar effect but not nearly so 
dramatic;

it's closer to proportionate for the workload (number of list items).

After the results, is the code that's being profiled

-ernie

=== summary results

   1x33   1x65   1x99   2x33   2x65

Re: map() slows down dramatically after vim running a while

[Ernie Rael]

On 23/03/20 10:56 PM, Ernie Rael wrote:

It is the profiling itself that is causing the results to be so skewed as
things run longer. I guess the thing to do now is use the linux/gnu
profiler to profile the vim profiler.



Found it.

Doing
    execute 'profile func' funcref(Func)->get('name')
    profile start xxx.profile.out
generates
    Error detected while processing command line..script 
/home/err/play/xxx.vim:

    line   15:
    E750: First use ":profile start {fname}"
I assumed (bad programmer) that the list of functions to profile is
cleared by `profile stop`; after all you can't set the functions
without doing `profile start`.

So I've been doing
    profile start xxx.profile.out
    execute 'profile func' funcref(Func)->get('name')
    Func()
    profile stop
and this gets done multiple times while collecting data.

Here's some gprof output
  %   cumulative   self  self total
 time   seconds   seconds    calls  ms/call  ms/call  name
 31.82  0.07 0.07   542508 0.00 0.00 nfa_regmatch
Without a function name being set multiple times nfa_regmatch
is at most a blip. BTW, the name looks like `47_T`.

This profiling behavior is confusing at best.

Throwing out duplicate patters is a thought.
I wonder if `function name {pattern}` that don't require regexp
could/should be handled without it; maybe a table lookup.

-ernie




During a single run of vim, for the current analysis, 45 profile files 
are

created; the profile structures are torn down and rebuilt 45 times. I've
modified my profiling framework such that all the programs are still run,
but the profiler is enabled on a per column basis. In addition the output
shows the run order of the various columns.

Only the 3rd and 9th columns are profiled
   1x99   3x99 : nInputXnLoop (cells: usec/op)
 #3 #9 : run order
  0.596  1.177 : map(in, 'v:val')   ###-2
  3.110 17.203 : map(in, Map1)   ###-6

Reverse order
   1x99   3x99 : nInputXnLoop (cells: usec/op)
 #7 #1 : run order
  0.644  1.068 : map(in, 'v:val')   ###-2
  6.113  4.903 : map(in, Map1)   ###-6

All 9 columns are profiled
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
 #1 #2 #3 #4 #5 #6 #7 #8 #9 : run 
order
  0.608  0.592  0.603  0.941  0.954  0.976  1.269  1.217  1.208 : 
map(in, 'v:val')   ###-2
  2.550  5.884 10.559 26.990 36.463 44.996 79.196 90    106 : 
map(in, Map1)   ###-6


All columns profiled in reverse order
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
 #9 #8 #7 #6 #5 #4 #3 #2 #1 : run 
order
  0.789  0.735  0.682  0.975  1.690  0.932  1.209  1.108  1.059 : 
map(in, 'v:val')   ###-2
 34.596 30.699 27.083 50.110 77.150 28.901 31.590 17.570  4.486 : 
map(in, Map1)   ###-6


In the previous results, excepting for the first and last columns, the
order of the column execution was incorrectly stated. The conclusions are
the same and the results make more sense now.


On 23/03/20 5:33 PM, Ernie Rael wrote:
Is this expected? All the results/table are collected in a single 
instance

of vim; tried it with "-u NONE". I've run asan and valgrind on
test_filter_map and don't see any leaks. If these results are a 
surprise, I

can look further. I haven't run the linux/gnu profiler yet. I saw vim's
MEM_PROFILE, I'll check that out. Other suggestions for investigation?
Not just map, but that's part of what I'm looking at now.

Looking to understand some profiling results.
In the following nInput is number of items in "input: list"
The code is run 5 times with the specified parameters nInputXnLoop.
Each cell is the fastest result of the 5 runs.

The first set of results are execute left to right, the second set 
are run
right to left. I had incorrectly thought that more work and higher 
number

of loops caused the slower results; but it seems that the greatest
contributor to slowdown is how much vim's been running. The most 
dramatic

difference can be seen
    in 3x99 (list of 3 numbers, 99 loops) for map(in, Map1)
    119 usec/op vs 5 usec/op.
Note that map(in, 'v:val') has a similar effect but not nearly so 
dramatic;

it's closer to proportionate for the workload (number of list items).

After the results, is the code that's being profiled

-ernie

=== summary results

   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
  0.652  0.671  0.725  0.916  0.953  0.951  1.188  1.271  1.200 : 
map(in, 'v:val')   ###-2
  2.918 16.121 31.023 13.029 41.957 70.292 35.317 76.674    119 : 
map(in, Map1)   ###-6


REVERSE column order of execution
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 

Re: map() slows down dramatically after vim running a while

[Ernie Rael]

It is the profiling itself that is causing the results to be so skewed as
things run longer. I guess the thing to do now is use the linux/gnu
profiler to profile the vim profiler.

During a single run of vim, for the current analysis, 45 profile files are
created; the profile structures are torn down and rebuilt 45 times. I've
modified my profiling framework such that all the programs are still run,
but the profiler is enabled on a per column basis. In addition the output
shows the run order of the various columns.

Only the 3rd and 9th columns are profiled
   1x99   3x99 : nInputXnLoop (cells: usec/op)
 #3 #9 : run order
  0.596  1.177 : map(in, 'v:val')   ###-2
  3.110 17.203 : map(in, Map1)   ###-6

Reverse order
   1x99   3x99 : nInputXnLoop (cells: usec/op)
 #7 #1 : run order
  0.644  1.068 : map(in, 'v:val')   ###-2
  6.113  4.903 : map(in, Map1)   ###-6

All 9 columns are profiled
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)

 #1 #2 #3 #4 #5 #6 #7 #8 #9 : run order
  0.608  0.592  0.603  0.941  0.954  0.976  1.269  1.217  1.208 : 
map(in, 'v:val')   ###-2
  2.550  5.884 10.559 26.990 36.463 44.996 79.196 90    106 : 
map(in, Map1)   ###-6


All columns profiled in reverse order
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)

 #9 #8 #7 #6 #5 #4 #3 #2 #1 : run order
  0.789  0.735  0.682  0.975  1.690  0.932  1.209  1.108  1.059 : 
map(in, 'v:val')   ###-2
 34.596 30.699 27.083 50.110 77.150 28.901 31.590 17.570  4.486 : 
map(in, Map1)   ###-6


In the previous results, excepting for the first and last columns, the
order of the column execution was incorrectly stated. The conclusions are
the same and the results make more sense now.


On 23/03/20 5:33 PM, Ernie Rael wrote:
Is this expected? All the results/table are collected in a single 
instance

of vim; tried it with "-u NONE". I've run asan and valgrind on
test_filter_map and don't see any leaks. If these results are a 
surprise, I

can look further. I haven't run the linux/gnu profiler yet. I saw vim's
MEM_PROFILE, I'll check that out. Other suggestions for investigation?
Not just map, but that's part of what I'm looking at now.

Looking to understand some profiling results.
In the following nInput is number of items in "input: list"
The code is run 5 times with the specified parameters nInputXnLoop.
Each cell is the fastest result of the 5 runs.

The first set of results are execute left to right, the second set are 
run

right to left. I had incorrectly thought that more work and higher number
of loops caused the slower results; but it seems that the greatest
contributor to slowdown is how much vim's been running. The most dramatic
difference can be seen
    in 3x99 (list of 3 numbers, 99 loops) for map(in, Map1)
    119 usec/op vs 5 usec/op.
Note that map(in, 'v:val') has a similar effect but not nearly so 
dramatic;

it's closer to proportionate for the workload (number of list items).

After the results, is the code that's being profiled

-ernie

=== summary results

   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
  0.652  0.671  0.725  0.916  0.953  0.951  1.188  1.271  1.200 : 
map(in, 'v:val')   ###-2
  2.918 16.121 31.023 13.029 41.957 70.292 35.317 76.674    119 : 
map(in, Map1)   ###-6


REVERSE column order of execution
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
  0.859  0.768  0.656  1.091  1.007  0.887  1.299  1.281  1.061 : 
map(in, 'v:val')   ###-2
 40.001 28.434 12.215 69.711 41.915 13.326 89.459 52.533  4.873 : 
map(in, Map1)   ###-6



=== full results

$ ./vimprof_summarize | ./vimprof_create_table
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
  0.074  0.070  0.071  0.073  0.074  0.069  0.074  0.078  0.069 : 
result = []   ###-0
  0.155  0.161  0.173  0.190  0.202  0.192  0.209  0.222  0.206 : in = 
input->copy()   ###-1
  0.652  0.671  0.725  0.916  0.953  0.951  1.188  1.271  1.200 : 
map(in, 'v:val')   ###-2
  0.077  0.077  0.080  0.080  0.083  0.084  0.082  0.087  0.083 : 
result = []   ###-4
  0.156  0.157  0.156  0.186  0.190  0.187  0.209  0.215  0.211 : in = 
input->copy()   ###-5
  2.918 16.121 31.023 13.029 41.957 70.292 35.317 76.674    119 : 
map(in, Map1)   ###-6
  0.082  0.090  0.098  0.087  0.098  0.097  0.092  0.102  0.098 : 
result = []   ###-8


REVERSE

$ ./vimprof_summarize | ./vimprof_create_table
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
  0.092  0.076  0.070  0.092  0.076  0.070  0.082  0.081  0.066 : 
result = []   ###-0
  0.177  0.163  0.157  0

map() slows down dramatically after vim running a while

[Ernie Rael]

Is this expected? All the results/table are collected in a single instance
of vim; tried it with "-u NONE". I've run asan and valgrind on
test_filter_map and don't see any leaks. If these results are a surprise, I
can look further. I haven't run the linux/gnu profiler yet. I saw vim's
MEM_PROFILE, I'll check that out. Other suggestions for investigation?
Not just map, but that's part of what I'm looking at now.

Looking to understand some profiling results.
In the following nInput is number of items in "input: list"
The code is run 5 times with the specified parameters nInputXnLoop.
Each cell is the fastest result of the 5 runs.

The first set of results are execute left to right, the second set are run
right to left. I had incorrectly thought that more work and higher number
of loops caused the slower results; but it seems that the greatest
contributor to slowdown is how much vim's been running. The most dramatic
difference can be seen
    in 3x99 (list of 3 numbers, 99 loops) for map(in, Map1)
    119 usec/op vs 5 usec/op.
Note that map(in, 'v:val') has a similar effect but not nearly so dramatic;
it's closer to proportionate for the workload (number of list items).

After the results, is the code that's being profiled

-ernie

=== summary results

   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
  0.652  0.671  0.725  0.916  0.953  0.951  1.188  1.271  1.200 : 
map(in, 'v:val')   ###-2
  2.918 16.121 31.023 13.029 41.957 70.292 35.317 76.674    119 : 
map(in, Map1)   ###-6


REVERSE column order of execution
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
  0.859  0.768  0.656  1.091  1.007  0.887  1.299  1.281  1.061 : 
map(in, 'v:val')   ###-2
 40.001 28.434 12.215 69.711 41.915 13.326 89.459 52.533  4.873 : 
map(in, Map1)   ###-6



=== full results

$ ./vimprof_summarize | ./vimprof_create_table
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
  0.074  0.070  0.071  0.073  0.074  0.069  0.074  0.078  0.069 : 
result = []   ###-0
  0.155  0.161  0.173  0.190  0.202  0.192  0.209  0.222  0.206 : in = 
input->copy()   ###-1
  0.652  0.671  0.725  0.916  0.953  0.951  1.188  1.271  1.200 : 
map(in, 'v:val')   ###-2
  0.077  0.077  0.080  0.080  0.083  0.084  0.082  0.087  0.083 : 
result = []   ###-4
  0.156  0.157  0.156  0.186  0.190  0.187  0.209  0.215  0.211 : in = 
input->copy()   ###-5
  2.918 16.121 31.023 13.029 41.957 70.292 35.317 76.674    119 : 
map(in, Map1)   ###-6
  0.082  0.090  0.098  0.087  0.098  0.097  0.092  0.102  0.098 : 
result = []   ###-8


REVERSE

$ ./vimprof_summarize | ./vimprof_create_table
   1x33   1x65   1x99   2x33   2x65   2x99   3x33   3x65   3x99 : 
nInputXnLoop (cells: usec/op)
  0.092  0.076  0.070  0.092  0.076  0.070  0.082  0.081  0.066 : 
result = []   ###-0
  0.177  0.163  0.157  0.193  0.182  0.177  0.211  0.208  0.180 : in = 
input->copy()   ###-1
  0.859  0.768  0.656  1.091  1.007  0.887  1.299  1.281  1.061 : 
map(in, 'v:val')   ###-2
  0.082  0.079  0.078  0.084  0.081  0.080  0.080  0.083  0.077 : 
result = []   ###-4
  0.164  0.173  0.160  0.192  0.194  0.188  0.215  0.216  0.195 : in = 
input->copy()   ###-5
 40.001 28.434 12.215 69.711 41.915 13.326 89.459 52.533  4.873 : 
map(in, Map1)   ###-6
  0.111  0.102  0.091  0.117  0.107  0.093  0.111  0.113  0.079 : 
result = []   ###-8



=== code being profiled

def Map1(_, val: number): number
    return val
enddef

def Map(xxx: list)
    result = []   ###-0
    var in: list
    in = input->copy()    ###-1
    map(in, 'v:val')  ###-2
    if expect != in | Oops() | endif
    result = []   ###-4
    in = input->copy()    ###-5
    map(in, Map1) ###-6
    if expect != in | Oops() | endif
    result = []   ###-8
enddef

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/fab62a69-358d-d855-ab38-0fb565f17ddf%40raelity.com.

vim's "C" for loop coding style

[Ernie Rael]

Is "for (i = 0; i < len; i++, idx++)" OK style in vim?

-ernie

I'm looking at a change to a vim "C" file. It currently looks like

    for (i = 0; i < len; i++) {
    // stuff

    // more stuff

    ++idx;
    }

I need to make a change, the most clear (I think) is

    for (i = 0; i < len; i++, idx++) {
    // stuff

    if (cond)
    continue;

    // more stuff
    }

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/9a3c2ea2-8cf9-fc33-54b6-8488e4e1743e%40raelity.com.

Re: get({func}, "name"): is it behaving correctly?

[Ernie Rael]

On 23/03/18 1:29 PM, Bram Moolenaar wrote:

Ernie Rael wrote:


Doing

 def T()
 enddef
 echo T->get('name')
 echo T
 finish

produces this output

 <80>R34_T
 34_T

Is this expected? I just saw `T->get('name') and thought I could
use it to replace a spot where I'm extracting the name from `string(T)`.

I get:

E121: Undefined variable: T
E121: Undefined variable: T

When I prepend "vim9script" then I do get the output you mention.

The output looks OK, you get the internal name of a script-local
function.  Either the byte-code version or the printable version with
.  Note that you can also get the printable version with:

  echo function('T')->get('name')


Thanks. Now I get it; it's magic. (easier for me to understand than delving
into byte-code version and what I'd do with it.)

Never having learned vimscript, seems there are some things I'm not
easily getting a feel for, since with vim9script...

-ernie





--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/81307a37-c0eb-2c8b-f81b-f07cc7574442%40raelity.com.

get({func}, "name"): is it behaving correctly?

[Ernie Rael]

Doing

   def T()
   enddef
   echo T->get('name')
   echo T
   finish

produces this output

   <80>R34_T
   34_T

Is this expected? I just saw `T->get('name') and thought I could
use it to replace a spot where I'm extracting the name from `string(T)`.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ffa8eea1-3026-b80f-89a5-c16a09716f9c%40raelity.com.

Re: collection->foreach(func)

[Ernie Rael]

On 23/03/14 10:23 AM, Bram Moolenaar wrote:

Ernie Rael wrote:


I sometimes want "collection->foreach((_, v) => ...v...)", a simple
one liner, no return or return ignored. I know it's not a performance
winner, or I'd want it more.

After a quick look at the code, it looks like simply introducing
another filtermap_T, FILTERMAP_FOREACH, and there's not much coding
needed (I only looked at list). Probably more work doing tests/doc.

Any objections or other considerations?

So, this would iterate over the items in a List or Dictionary and invoke
a function for each one.  I assume the List or Dictionary is not
modified, otherwise you would use map().
Yes, yes. Not modified as though `lockvar 1`, a structured value, like 
an inner list in a list of lists, could be modified.

Thus it's a short version of a
for loop.  This seems useful.

I would suggest first writing the help and think of any error conditions
that need to be handled.

The first PR will be doc only.

   Perhaps the collection should be locked
(frozen) to avoid trouble?


To protect against the script changing the list/dict top level structure 
during iteration? Aren't map/filter/mapnew susceptible to the script 
manipulating the source collection during iteration?


But it's always nice to get an exception if the script misbehaves. In 
this case, there can be no structure modification, unlike map/filter. I 
suppose with map/filter the list could be locked during the operation 
except when the return from the function indicates a change needs to be 
made (I've never looked at the lock code; have no idea of the overhead 
of an internal `lockvar 1`)


-ernie





--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/2b709080-3f01-a2d4-2202-56adc48208b7%40raelity.com.

Re: collection->foreach(func)

[Ernie Rael]

On 23/03/14 12:45 PM, Marvin Renich wrote:

* Bram Moolenaar  [230314 13:24]:

Ernie Rael wrote:


I sometimes want "collection->foreach((_, v) => ...v...)", a simple
one liner, no return or return ignored. I know it's not a performance
winner, or I'd want it more.

After a quick look at the code, it looks like simply introducing
another filtermap_T, FILTERMAP_FOREACH, and there's not much coding
needed (I only looked at list). Probably more work doing tests/doc.

Any objections or other considerations?

So, this would iterate over the items in a List or Dictionary and invoke
a function for each one.  I assume the List or Dictionary is not
modified, otherwise you would use map().  Thus it's a short version of a
for loop.  This seems useful.

I would suggest first writing the help and think of any error conditions
that need to be handled.  Perhaps the collection should be locked
(frozen) to avoid trouble?

Would this have any functionality that is not provided by using mapnew
and ignoring or throwing away the result?


All the existing functions, map/mapnew/filter, require a return value; 
that makes it impossible to have a one line lambda with a rhs that isn't 
a value. And requiring a new list to be built is painful.


-ernie


...Marvin



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ce905ad3-a101-b9ec-d989-c4949a97f0d4%40raelity.com.

collection->foreach(func)

[Ernie Rael]

I sometimes want "collection->foreach((_, v) => ...v...)", a simple
one liner, no return or return ignored. I know it's not a performance
winner, or I'd want it more.

After a quick look at the code, it looks like simply introducing
another filtermap_T, FILTERMAP_FOREACH, and there's not much coding
needed (I only looked at list). Probably more work doing tests/doc.

Any objections or other considerations?

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/b8e2b8fa-c6d8-cc41-ac63-6b1d21a75f41%40raelity.com.

FYI: wrong indent in vim9compile.c

[Ernie Rael]

"goto theend" around line 2649.


    if (*p != '=' && need_type(rhs_type, lhs_type, FALSE,
    -1, 0, cctx, FALSE, FALSE) == FAIL)
    goto theend;
    }
    }
    else if (cmdidx == CMD_final)
    {
    emsg(_(e_final_requires_a_value));

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/edf61b85-35de-8415-73b0-1bf885d459aa%40raelity.com.

Re: Wondering about "dict->putifabsent(k,v)"

[Ernie Rael]

On 23/03/07 11:10 AM, Ernie Rael wrote:

On 23/03/07 9:14 AM, Bram Moolenaar wrote:

Ernie Rael wrote:



I was surprised to see a user function ~1,000 times slower.

Invoking a user function has a lot of overhead.  You did use a compiled
function?
I did. But I was uncomfortable with the results; finally this morning 
it occurred to me that I wasn't using the profiler correctly for micro 
benchmarking and I'm looking at that right now. I don't believe the 
function is 1,000 slower, maybe more like 100 times slower. 


My hand slapping against my forehead...

Turns out the main performance issue is that I was running the test by 
doing "source %" in a gvim that had been running for a while. 
PutIfAbsent(), run from gvim that's been running for a long time, can be 
around 12x slower than than when run from the command line as "gvim -c 
'source test.vim' -c q". Alloc/free?


And curiously, when run from the command line, gvim is 50% slower than 
vim. Some results below, the "command line" results are repeatable. 
Doing ":source" in a just started gvim, versus command line gvim, is 
~20% faster, I'm guessing that's because gvim has time to get to a 
quiescent state before the test is run.


Note that only the user function implementation (which takes much longer 
than anything else) shows such a huge variation in performance. The 
bottom line is that the user function PutIfAbsent is ~30 times slower 
than extend({[k]: v}, 'keep') when run with vim from command line.


-ernie

Using running for a while gvim, :sou %
   10   30   65  100  200  300 : nKeys 
(micro-sec/algorithm)
  293  308  305  311  318  323 : 
d->PutIfAbsent(k, v)
    0.468    0.448    0.465    0.484    0.467    0.488 : 
d->extend({[k]: v}, 'keep')


Using gvim from command line
$ gvim -c 'source test.vim' -c q
    1.276    5.895   10.580   15.006   19.510   24.190 : 
d->PutIfAbsent(k, v)
    0.479    0.476    0.473    0.464    0.477    0.493 : 
d->extend({[k]: v}, 'keep')


Using console vim from command line
$ vim -c 'source test.vim' -c q
    0.974    4.223    7.227   10.401   13.967   16.784 : 
d->PutIfAbsent(k, v)
    0.478    0.476    0.464    0.469    0.471    0.491 : 
d->extend({[k]: v}, 'keep')


Using fresh start gvim, :sou
    1.038    4.948    8.836   12.581   16.383   20.328 : 
d->PutIfAbsent(k, v)
    0.477    0.470    0.454    0.455    0.456    0.491 : 
d->extend({[k]: v}, 'keep')



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/c5cf222b-a0c6-8fd2-3ee8-d11df6123865%40raelity.com.

Re: Wondering about "dict->putifabsent(k,v)"

[Ernie Rael]

On 23/03/07 9:14 AM, Bram Moolenaar wrote:

Ernie Rael wrote:


Is it worth adding a putifabsent(dict, key, value) builtin function?
Discuss among yourselves ;-)

...

"d->extend({k: v})" is the only builtin way (that I know of).
...
I was surprised to see a user function ~1,000 times slower.

Invoking a user function has a lot of overhead.  You did use a compiled
function?
I did. But I was uncomfortable with the results; finally this morning it 
occurred to me that I wasn't using the profiler correctly for micro 
benchmarking and I'm looking at that right now. I don't believe the 
function is 1,000 slower, maybe more like 100 times slower.



The profiling, in micro-sec/op, is of putting a single k,v into a
dictionary; the key is already in the target dictionary, column header
is the number of keys in the target dictionary. There's something
curious going on around 200 keys.

I don't think adding a function specifically to make something a bit
faster is a good idea.
Agreed, that's the conclusion I came to. And for this case, extend looks 
good and works well, I got started on this because a user function was 
so slow.

  Using extend() should work, perhaps a little
profiling can show how to make it go faster.
Maybe, at first glance it looks like building the temp dictionary to 
pass to extend is ~1/3 of the time.

  It might be that looping
over the dictionary to find the one entry adds some overhead (there are
always empty entries in the dictionary to make adding more items fast).


Might take a look (I always enjoy running a profiler :-) )

-ernie






--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/0308cd44-f8c5-a664-d9ad-3c80709332a6%40raelity.com.

scrolling back in gdb command window

[Ernie Rael]

Using Termdebug, in the gdb command windows is there a way to scroll 
back to see earlier commands and output?


-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/c6e43d6f-7070-e6ca-385c-59793aab0fd9%40raelity.com.

stack trace issues

[Ernie Rael]

Hi all,

I've got logging stuff, vim9script, that creates a stacktrace:

    splicelib/init.vim::Process_result[1]
    splice9Dev#splicelib#init#Init[1]
    splice9Dev/splice.vim::SpliceInit9[10]
    function splice9Dev/splice.vim::Trampoline[6]

I've discovered another twist, after , that some frames use "#" as 
separator.


If I see a name with a "#", split on "#", use last component as function 
and append ".vim" to the second to the last. May not be perfect (e.g. no 
requirement for ".vim" extension) but should be good enough.


Comments? or any other gotchas I should be aware of?

BTW, what's the significance of the "#"?

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/bba7c8c3-d9a9-0416-763c-dc51ff043951%40raelity.com.

object and '==' versus 'is'

[Ernie Rael]

Just checking...

Doing "o1 == o2" checks o1,o2 same class type and "o1.member == 
o2.member" for all members.


Doing "o1 is o2" checks if o1 and o2 are the same objects (same address)

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6d09c0d5-c5b0-a3e8-66e9-018342dd106a%40raelity.com.

Re: convert ##_ to a filename

[Ernie Rael]

On 23/02/25 2:23 PM, Bram Moolenaar wrote:

Ernie Rael wrote:


I'm playing around with putting a stacktrace in a log file. I probably
want to include the script file name. Example stacktrace is

 31_Baz[1]
 31_Bar[1]
 function 31_Foo[1]
 script /home/err/play/xxx.vim[27]

I tried

 expand("31")

I see ":scriptnames", and I just found scriptnames-dictionary, so I
guess that's the route to take. I suppose if I encounter a  that's
not in cached dictionary, I should run it again. Unless of course
there's some builtin support since scriptnames-dictionary was written
that I can't find.

Is a patch to eval.txt of interest to use a vim9 function instead?

There actually is getscriptinfo().  Have a look at it, parsing the
output of :scriptnames might not be needed.

I'll mention getscriptinfo() in a couple of places, it is not so easy to
find.


Thanks, perfect. Update PR#12062 to use getscriptinfo().

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/f3cca812-f58b-80dc-f3cd-4a0041e1bc01%40raelity.com.

convert ##_ to a filename

[Ernie Rael]

I'm playing around with putting a stacktrace in a log file. I probably 
want to include the script file name. Example stacktrace is


   31_Baz[1]
   31_Bar[1]
   function 31_Foo[1]
   script /home/err/play/xxx.vim[27]

I tried

   expand("31")

I see ":scriptnames", and I just found scriptnames-dictionary, so I 
guess that's the route to take. I suppose if I encounter a  that's 
not in cached dictionary, I should run it again. Unless of course 
there's some builtin support since scriptnames-dictionary was written 
that I can't find.


Is a patch to eval.txt of interest to use a vim9 function instead?

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/e2b0b719-03cf-4997-3536-3408d7f2b84f%40raelity.com.

Re: edit buffer using a builtin function

[Ernie Rael]

On 23/02/22 4:53 PM, Maxim Kim wrote:


Is there a builtin function to edit a buffer in the current window?

 There is no function as far as I know for this.

I use

execute string(bnr) .. 'buffer'

Anything more script oriented?

Pretty much this, with variations using string interpolation:

:exe $"{bnr}buffer"
:exe $"b {bnr}"


Thanks, hadn't thought of string interpolation

Looking again I saw that ":5buffer" and ":buffer 5" are the same (as you 
show, and I should have known)


I've started using

    execute 'buffer' bnr

-ernie



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6fb57b3e-1b3c-4379-b0e9-341ba69e30f0n%40googlegroups.com 
.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/469fda24-9fe8-7716-b26b-bc6ee8fb796e%40raelity.com.

edit buffer using a builtin function

[Ernie Rael]

Is there a builtin function to edit a buffer in the current window?

I use

   execute string(bnr) .. 'buffer'

Anything more script oriented?

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/f4ba5b45-f46e-43f6-6657-35270ac57785%40raelity.com.

Re: vim9 instanceof

[Ernie Rael]

On 23/02/10 12:50 PM, Bram Moolenaar wrote:

For now I'm using

 export def IsInstanceOf(o: any, type: string): bool
      return type(o) == v:t_object && type == typename(o)[7 : -2]
 enddef

Is there something better? A planned builtin?

I don't actually need it yet, but I'm just getting started and I know
how I am.

Implementing "instanceof" is in the todo list.  I haven't looked into
the details yet.  Probably similar to how Java works.  Although I have
always found it a bit confusing that it results in true for an object
that is a child of the class being tested with.


Yeah, In Java's java.lang.Class, there's both "isInstance(Object)" and
"isAssignableFrom(Class); they both basically test assignment 
compatibility,

same as the languages "instanceof" operator.

And with that reminder, I'm changing the name of my temporary helper 
class to


   export def IsSameType(o: any, type: string): bool

since it doesn't test assignment compatibility. (And for now don't worry 
about

same class name but different file.)

-ernie



I have also been thinking of an alternative of type() that includes the
exact class.  So that you could do:

type_ext(object) == type_ext(SomeClass.new())

Similar to typename(), except that it would make a difference between
classes with the same name declared in different scripts.  Hmm, perhaps
adding the script number would work?  Thus if you define a class MyClass
in script 4 and script 7, you would get:
object
object

This win't work if a class can be defined more than once in one script
file.  E.g. when it's local to a function.  An alternative is to give
each encountered class a unique number.



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/c5001f6e-9927-edd0-aea2-fdf60f44edc1%40raelity.com.

vim9 instanceof

[Ernie Rael]

For now I'm using

   export def IsInstanceOf(o: any, type: string): bool
    return type(o) == v:t_object && type == typename(o)[7 : -2]
   enddef

Is there something better? A planned builtin?

I don't actually need it yet, but I'm just getting started and I know 
how I am.


-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/3666246c-4a4d-7d5c-67a9-af4fcf8cefb1%40raelity.com.

Re: prop_find extension

[Ernie Rael]

On 23/02/03 4:26 AM, Bram Moolenaar wrote:

Ernie Rael wrote:


I want to determine what text property, if any, is under the mouse
position. The best options seems to be

 prop_find({lnum: mpos.line, col: mpos.column, ...})

and then check if the returned property covers the mouse position.

I am wondering about having an "exact: true" option in prop_find's
"search for" options. When "exact: true" a property is only returned
if (lnum, col) are covered by the property, otherwise an empty
dictionary is returned.

Using this would minimize extra code, including vim9 code to check
if returned property covers mouse pos. This is used on every mouse
movement event, would be nice to minimize overhead.

Would a patch that adds "exact: true" be considered? I haven't looked
at the code yet; first looking for comments on this approach.

prop_find() can be inefficient, since it searches the whole buffer.
That is especially when no match is found.


Right. The idea is that when "exact: true", prop_find only checks if 
there is a prop
match at lnum/col. If there is a match, return the prop otherwise 
immediately return
empty; there is no search when "exact" is true. I suppose 
"exact_location" is more

descriptive, but longer.



How about using prop_list() instead?  It only checks for properties in
one line, which is what you want.  We could add a "col" entry in the
{props} argument to narrow down to properties that include this column.


The current prop_list is not too bad since the search already can be 
limited. Still requires
searching the returned list. Was trying to avoid checking if the 
returned props overlap
mouse pos, but I tend to over optimize while looking to minimize 
vim9script code in favor

of  builtins.

I almost didn't mention it at all since it does seem pretty minor, I 
even thought about
prop_find_at(...) which implies exact and lnum/col could be required 
positional args.

Like I said, tend to over optimize.

-ernie


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/d756524c-817b-8346-1fc6-b7ebf847819a%40raelity.com.

prop_find extension

[Ernie Rael]

I want to determine what text property, if any, is under the mouse
position. The best options seems to be

   prop_find({lnum: mpos.line, col: mpos.column, ...})

and then check if the returned property covers the mouse position.

I am wondering about having an "exact: true" option in prop_find's
"search for" options. When "exact: true" a property is only returned
if (lnum, col) are covered by the property, otherwise an empty
dictionary is returned.

Using this would minimize extra code, including vim9 code to check
if returned property covers mouse pos. This is used on every mouse
movement event, would be nice to minimize overhead.

Would a patch that adds "exact: true" be considered? I haven't looked
at the code yet; first looking for comments on this approach.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/df7e9bcc-4c6d-995e-6b32-cf681ffeaaed%40raelity.com.

Re: Class implementation

[Ernie Rael]

On 23/02/02 9:28 AM, Bram Moolenaar wrote:

Doug Kearns wrote:


I was just looking at the constructor documentation and noticed that the
default constructor includes parameters for each field in the order they
were declared.  Having to change all the constructor call sites when
reordering field declarations seems like a probable source of bugs,
particularly when switching fields of the same type.  This seems like a
feature that really needs named-parameter support.

Good point.  Although I doubt it would happen often, it can be difficult
to figure out what went wrong when it does happen.

What we could do:

1. Do not change how it works, add remarks to the help warning for
changing the member ordering.


BTW, it's easy to avoid the situation, add

   def new()
   enddef

to any class where you don't want the default constructor.

Without this, a lint could produce a warning about using default 
constructor.


-ernie



2. Make the default new() method not accept arguments.  The caller must
set the fields after calling new().  This is safe, but requires
several extra lines.
var obj = Class.new()
obj.line = 5
obj.column = 0

3. Add a mechanism to name the members in the call, e.g.
var obj = Class.new(line = 5, column = 0)
This is similar to 2. but puts it in one line.
It requires marking a method to not use positional arguments.a

Although 3. looks like a good solution, it requires implementing a new
mechanism.  And disallowing positional arguments might be considered
weird, I cannot think of a language that has this functionality.




--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/651cb7ef-35b2-697e-6e15-fec7003c31be%40raelity.com.

Re: vim9script: how to find current executing file path

[Ernie Rael]

On 23/01/29 5:33 AM, Bram Moolenaar wrote:

Ernie Rael wrote:


If I could get the realpath of the file that's executing

It's not clear what files you are working with.  If they are Vim script,
you can get the full path of the script with:

echo expand(':p')

or:

echo expand('

Re: vim9script: how to find current executing file path

[Ernie Rael]

On 23/01/28 10:09 AM, Ernie Rael wrote:
I'm working on a project with several files. I try to mostly work in a 
"dev" location where I can run the various files individually; the 
files usually have a in_dev flag, which sets things up to run 
standalone (often simply adjusting imports). When ready to run in the 
application, I copy the file to their "real" location and manually 
adjust what's needed in the files. The manual step is a hassle.


If I could get the realpath of the file that's executing I could set 
the flags when the file is first loaded (and remember to do "source %" 
and not "source" while playing), and not need manual adjustments.


Then I can automate the update of the app files.

-ernie


For my use case, I think I can simply use the current directory.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/f984d1c0-da52-941c-2c49-c5245e57950d%40raelity.com.

vim9script: how to find current executing file path

[Ernie Rael]

I'm working on a project with several files. I try to mostly work in a 
"dev" location where I can run the various files individually; the files 
usually have a in_dev flag, which sets things up to run standalone 
(often simply adjusting imports). When ready to run in the application, 
I copy the file to their "real" location and manually adjust what's 
needed in the files. The manual step is a hassle.


If I could get the realpath of the file that's executing I could set the 
flags when the file is first loaded (and remember to do "source %" and 
not "source" while playing), and not need manual adjustments.


Then I can automate the update of the app files.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/73a16ae0-546c-6551-cff5-b0e405907ddc%40raelity.com.

Re: Class implementation

[Ernie Rael]

On 23/01/24 10:23 AM, Ernie Rael wrote:

On 23/01/23 4:53 AM, Bram Moolenaar wrote:

I expected a lively discussion about alternatives for the class
implementation, but nothing much happened.  Does this mean that most
people agree with making this changed:

1. Make object members public by default.  They can be read and written
from anywhere.

2. The only other possibility is making the object members private.
This is done with the existing mechnism to prefix an underscore to
the name.

This simplifies things, there is no "read-only" access mode, which is
currently the default.  There is no need for a "plublic" keyword.  This
is a bit limited, but it's simple.  And making things simple is part of
the goals for the Vim9 script syntax.

Unless there are relevant objections, I'll make this change.



In a previous comment on this, I said


Guess I'm looking for a way that a trusted group of
classes can have full access; but I'm not sure how important that really
is (and I'm not sure how I feel about a bunch of classes in a single
file).


But while exploring porting some python code to vim9 I realized that I
generally use lots of classes in a single file; but they are nested
classes and that's one of the primary ways that private members are
used from the outside (I'm talking about java, not python).

I can probably achieve a lot of this by having a given object save
functions/lambdas that access private stuff into function variables
within the file and then use those functions from within the file.
Sounds messy, but I don't like having stuff public outside of trusted
code.

I'm trying to experiment with this approach, but classes aren't ready
for it yet. Here's what I'm thinking might work. It depends on a static
class method being able to access private object members, something like
the **private** method `StaticModX` in the following, and then the func
`AccessXxxx` give stuff in the file access to private members. (Might
want to have InitLocalAccessFunctions private and executed only the
first time the constructor is called)

var AccessXxxx: func

class X
this._xxx: string

def new(this._xxx)
enddef

static def StaticModX(x: X, val: string)
x._xxx = val
enddef

static def InitLocalAccessFunctions()
AccessXxxx = X.StaticModX
enddef
endclass

X.InitLocalAccessFunctions()

o = X.new("some_string")
AccessXxxx(o, "different_string")


-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/566b572b-dde4-ad60-5f0b-3478ae66134d%40raelity.com.

Re: ctags for vim9script

[Ernie Rael]

On 23/01/24 11:50 PM, Christian Brabandt wrote:

On Di, 24 Jan 2023, Ernie Rael wrote:


I'm just updating to v6.0 u-ctags. I haven't tried using ctags/tags on
vim9script.

Wondering how well that works, any suggestions on getting a good tags file
for vim9script?

":help ctags" doesn't list a program that's good for vim9script ;-)

There was some discussion on how to configure tagbar and ctags
integration with Vim9 previously here:

https://groups.google.com/g/vim_use/c/hp4KeIsDlFU/m/Qn89ormhBAAJ



Thanks, what I was looking for. (thoping for class, but since in flux...)

Classes,interfaces can probably be handled the regex way.
Methods seem trickier.

-ernie



Best,
Christian



--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/4dcb6e8b-2c00-183d-6cca-f5dffdfc8dcc%40raelity.com.

ctags for vim9script

[Ernie Rael]

I'm just updating to v6.0 u-ctags. I haven't tried using ctags/tags on 
vim9script.


Wondering how well that works, any suggestions on getting a good tags 
file for vim9script?


":help ctags" doesn't list a program that's good for vim9script ;-)

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/29a13bdd-ec4c-6bd8-d839-41eb78397906%40raelity.com.

Re: Class implementation

[Ernie Rael]

On 23/01/23 4:53 AM, Bram Moolenaar wrote:

I expected a lively discussion about alternatives for the class
implementation, but nothing much happened.  Does this mean that most
people agree with making this changed:

1. Make object members public by default.  They can be read and written
from anywhere.

2. The only other possibility is making the object members private.
This is done with the existing mechnism to prefix an underscore to
the name.

This simplifies things, there is no "read-only" access mode, which is
currently the default.  There is no need for a "plublic" keyword.  This
is a bit limited, but it's simple.  And making things simple is part of
the goals for the Vim9 script syntax.

Unless there are relevant objections, I'll make this change.


This makes me uncomfortable at first consideration; allowing random
actors, by default, to modify internal state of other plugins does not
seem to support reliability. BUT...

I have no experience with legacy vimscript, I've seen that a dict is
used as an "object". So I guess the proposed access control, with "_"
for private allows protection in vim9script.

That said, by default having r/w access within the defining file would
be nice (kinda like a java package with multiple classes in a single
file), and default access private to other files. Use public for access
outside the file. Guess I'm looking for a way that a trusted group of
classes can have full access; but I'm not sure how important that really
is (and I'm not sure how I feel about a bunch of classes in a single
file). It seems some sort "package" access mechanism could be compatibly
added if it turns out it's needed. One area where it might be
particularly useful is vim9script libraries.

But I enjoy and sometimes use python (and I occasionally do things I'd
call cheating), I'm a fan of simplicity. I ported half of a vim/python
hybrid plugin to vim9 leaving the primary class structure in python; I'm
looking forward finishing it with vim9script classes, no matter what the
rules are, and having a pure vim plugin.

-ernie

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/d4e8f8e0-c7b1-6e06-9567-3a904a62b1a0%40raelity.com.

Re: Choices for Vim9 class implementation

[Ernie Rael]

On 22/12/25 2:54 PM, Christopher Plewright wrote:



On Monday, 26 December 2022 at 09:08:22 UTC+11 err...@raelity.com wrote:

On 22/12/25 1:07 PM, Bram Moolenaar wrote:

With 9.0.1094, in the script that follows, attempting to read a
classMember through  an instance fails;

 echomsg c.classMember

should it?

No, an object does not provide a class member.


I suppose requiring the class name makes it most clear, but I recall
mention that classnames can get long. I suppose a getter could be added.

How can you access the getter without referring to the class?



Assuming c is an object

c.GetClassMember()

where the method GetClassMember() returns the classMember that was
declared static.


Can a class method (or should it be called class function?) be static?

Nothing *is* static, the "static" keyword is used to change the meaning
of items.


I should have said "can a method/function defined in a class be
declared static?"

I don't think it's a good idea to access static class function from an 
object instance of that class.


I was not suggesting that. I've botched the question. I was saying that 
to get a class member (something declared static) from an object, there 
could be an instance method that returns the class member.


And I didn't know that it was documented that a function could be 
declared static; missed that, my bad.


   Also, I would not name that function with "Member" if it is a 
static function, because member implies that it is a member method of 
an object instance.  I think that could lead to confusion for someone 
else trying to read your code.
The difference between a function and a method is important - with 
regard to this topic of classes vs objects of the class.   According 
to Bram's preliminary doco.  Yes, class "method" can be declared 
static.  But then, I think that makes it a static class "function", 
and not a class "method".


Bram, I think that the doco here is referring to a class "function", 
not a class "method".  It might be worth distinguishing between method 
and function in the doco?
I should have studied the docs better, but yes, method for instance and 
function for class works for me.


Ref:
https://github.com/vim/vim/blob/b3d614369fceb891819badc941f80f08f57831f9/runtime/doc/vim9class.txt#L261-L275


One way to look at it: is it the case that any method can be
invoked as

MyClass.SomeMethod()

and as long as "SomeMethod()" doesn't reference a variable like
"this.someVar" then it's OK?

-ernie


How would Vim know when that is an error or not, if you didn't specify 
the static keyword when declaring the static class function.


I didn't know it was documented that there could be a static class 
function. The whole point of the question was to determine if there 
could be a static class function.


Sorry for the noise and confusion,
-ernie

 You want Vim to treat it as if it was a static class function, but 
wouldn't Vim need to analyse deeper to see if it uses any object 
members, to be able to allow that?




--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google 
Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/656faf72-e6a1-452c-bd25-59c22a071115n%40googlegroups.com 
.


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/17616c43-f454-b648-89b8-2cd64a74d7fa%40raelity.com.