Error during training because of float length of sequence(?)

Describe the bug
Hi, I have the following issue:
when I am trying to train my model using trainer.run(), I get the following error:
Traceback (most recent call last):
  File "/Users/xx/.conda/envs/QL_QA/lib/python3.7/site-packages/IPython/core/interactiveshell.py", line 3331, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-67-041e2033e90a>", line 1, in <module>
    trainer.run()
  File "/Users/xx/.conda/envs/QL_QA/lib/python3.7/site-packages/matchzoo/trainers/trainer.py", line 227, in run
    self._run_epoch()
  File "/Users/xx/.conda/envs/QL_QA/lib/python3.7/site-packages/matchzoo/trainers/trainer.py", line 251, in _run_epoch
    for step, (inputs, target) in pbar:
  File "/Users/xx/.conda/envs/QL_QA/lib/python3.7/site-packages/tqdm/std.py", line 1091, in __iter__
    for obj in iterable:
  File "/Users/xx/.conda/envs/QL_QA/lib/python3.7/site-packages/matchzoo/dataloader/dataloader.py", line 112, in __iter__
    self._handle_callbacks_on_batch_unpacked(x, y)
  File "/Users/xx/.conda/envs/QL_QA/lib/python3.7/site-packages/matchzoo/dataloader/dataloader.py", line 134, in _handle_callbacks_on_batch_unpacked
    self._callback.on_batch_unpacked(x, y)
  File "/Users/xx/.conda/envs/QL_QA/lib/python3.7/site-packages/matchzoo/dataloader/callbacks/padding.py", line 158, in on_batch_unpacked
    self._pad_word_value, dtype=dtype)
  File "/Users/xx/.conda/envs/QL_QA/lib/python3.7/site-packages/numpy/core/numeric.py", line 325, in full
    a = empty(shape, dtype, order)
TypeError: 'numpy.float64' object cannot be interpreted as an integer

I am not 100% sure, but it seems to me that the error is caused by the fact that in my preprocessed datapack, length_right is a float instead of an int (that seems to be the case in the toy datasets.).
>> toy_datapack.frame()[['length_right','length_left']]
Out[13]:
    length_right  length_left
0             58           29
1             41           29
2             41           29
3             61           29
4            128           29
5            126           85
6            128           85

while
train_pack = mz.DataPack(relation=relation[relation.id_left.isin(qids['train'])].reset_index(drop=True),
                             left=left[left.index.isin(qids['train'])],
                             # right=right_train,
                             right=right_dict['train'],
                             )
    train_pack.frame().head().dtypes

Out[78]:
id_left          object
text_left        object
id_right         object
text_right       object
length_right    float64
label           float64
dtype: object

It also seems weird to me that this is happening, since to my understanding, the built-in python len function should return an int.
right_train['length_right'] = right_train.text_right.apply(len)
Out[15]:

                                                                  text_right  length_right
id_right
clueweb09-en0007-21-42346  Welcome | Logout Log In | Sign Up The Huffingt...          4039
clueweb09-enwp03-01-16807  Ann Dunham From Wikipedia, the free encycloped...         32225
clueweb09-en0010-93-11767  Home Contact Us Bookmark Us Receive Family Tre...          5112
clueweb09-enwp01-36-17161  Maya Soetoro-Ng From Wikipedia, the free encyc...          8279
clueweb09-enwp00-34-05344  Barack Obama, Sr. From Wikipedia, the free enc...         14448
clueweb09-enwp00-34-05347  Barack Obama, Sr. From Wikipedia, the free enc...         14478

I am preparing my data using mz.autoprepare and the models I've tried to use are KNRM and DRMM, but the same issue still occurs.
My matchzoo.version`. = 1.1.1

I confirmed what I mentioned earlier regarding the cause of this problem:
I changed my script to a previous version, where a different document selection process (basically initial retrieval) was used, and indeed I observed that the training was running normally and the length_right was int instead of float.
Any ideas on what might be going wrong here or whether there should be a catch in the framework to fix that (eg. converting floats to int)?


Database Restore failed in Windows 10 64 bit

System information:

Operating system (distribution) and version: Windows 10 64 bit (version: 20H2)
DBeaver version: <IP_ADDRESS>105160657
Java version: JDK 11
Additional extensions

Connection specification:

Database name and version: MariaDB 10.5.10
Driver name: MariaDB
Do you use tunnels or proxies (SSH, SOCKS, etc)? No

Describe the problem you're observing:
Restore database always has errors.
Error executing process
  Cannot run program "C:\Users\Tom\AppData\Roaming\DBeaverData\drivers\clients\mysql\win\mysql.exe" (in directory "C:\Users\Tom\AppData\Roaming\DBeaverData\drivers\clients\mysql\win"): CreateProcess error=193, %1 is not a valid Win32 application
  Cannot run program "C:\Users\Tom\AppData\Roaming\DBeaverData\drivers\clients\mysql\win\mysql.exe" (in directory "C:\Users\Tom\AppData\Roaming\DBeaverData\drivers\clients\mysql\win"): CreateProcess error=193, %1 is not a valid Win32 application
    CreateProcess error=193, %1 is not a valid Win32 application
    CreateProcess error=193, %1 is not a valid Win32 application

Steps to reproduce, if exist:

Backup a database by tools dump: Right-click on the database → Tools → Dump Database → example.sql
Restore another database by tools restore: Right-click on the database → Tools → Restore Database → Choose the example.sql script
A window to show errors

Include any warning/errors/backtraces from the logs

I cannot reproduce it. Please try to select Local client before performing Restore procedure.

Could you also send file example to restore and log files completely https://github.com/dbeaver/dbeaver/wiki/Log-files?

Hi @kseniiaguzeeva, this is the log file which is created after restore failed: test_restore_error_2021-05-26.log
I can't upload the example SQL file. So I paste it in right here:
-- MySQL dump 10.13  Distrib 5.5.62, for Win64 (AMD64)
--
-- Host: localhost    Database: test_backup
-- ------------------------------------------------------
-- Server version	5.5.5-10.5.10-MariaDB

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `user`
--

DROP TABLE IF EXISTS `user`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(500) COLLATE utf8_unicode_ci NOT NULL,
  `age` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `user`
--

LOCK TABLES `user` WRITE;
/*!40000 ALTER TABLE `user` DISABLE KEYS */;
INSERT INTO `user` VALUES (1,'David',30),(2,'John',28);
/*!40000 ALTER TABLE `user` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Dumping routines for database 'test_backup'
--
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2021-05-26 16:50:39

If you need any information, please let me know. Thanks for your support.

Seems files were not downloaded properly. Could you delete them (you can see the way to the files in your error message) and then perform backup/restore? The files will be downloaded again by DBeaver.
Security policy in your company can be another reason. It can restrict to run some .exe files. Could you go to the file directory and try to run .exe file manually?

Seems files were not downloaded properly. Could you delete them (you can see the way to the files in your error message) and then perform backup/restore? The files will be downloaded again by DBeaver.
Security policy in your company can be another reason. It can restrict to run some .exe files. Could you go to the file directory and try to run .exe file manually?

Hi @kseniiaguzeeva, you are right.
I went to the file directory and try to run .exe file manually, it can't run.
I was deleted the C:\Users\Tom\AppData\Roaming\DBeaverData\drivers\clients\mysql\win\mysql.exe file and ran restore again.
It's working.
Thanks for your support.

Nice to hear)

Não consigo reproduzi-lo. Tente selecionar Cliente local antes de executar o procedimento de restauração.
Você também poderia enviar um exemplo de arquivo para restaurar e registrar arquivos completamente https://github.com/dbeaver/dbeaver/wiki/Log-files ?

Esta solução resolveu o meu caso .. de escolhendo o cliente escolhendo o Binário MySql 5 Binari

I cannot reproduce it. Please try to select Local client before performing Restore procedure.
Could you also send file example to restore and log files completely https://github.com/dbeaver/dbeaver/wiki/Log-files?

That worked for me, I dont have local client before. Thanks

System information:

Operating system (distribution) and version: Windows 10 64 bit (version: 20H2)
DBeaver version: <IP_ADDRESS>105160657
Java version: JDK 11
Additional extensions

Connection specification:

Database name and version: MariaDB 10.5.10
Driver name: MariaDB
Do you use tunnels or proxies (SSH, SOCKS, etc)? No

Describe the problem you're observing:
Restore database always has errors.
Error executing process
  Cannot run program "C:\Users\Tom\AppData\Roaming\DBeaverData\drivers\clients\mysql\win\mysql.exe" (in directory "C:\Users\Tom\AppData\Roaming\DBeaverData\drivers\clients\mysql\win"): CreateProcess error=193, %1 is not a valid Win32 application
  Cannot run program "C:\Users\Tom\AppData\Roaming\DBeaverData\drivers\clients\mysql\win\mysql.exe" (in directory "C:\Users\Tom\AppData\Roaming\DBeaverData\drivers\clients\mysql\win"): CreateProcess error=193, %1 is not a valid Win32 application
    CreateProcess error=193, %1 is not a valid Win32 application
    CreateProcess error=193, %1 is not a valid Win32 application

Steps to reproduce, if exist:

Backup a database by tools dump: Right-click on the database → Tools → Dump Database → example.sql
Restore another database by tools restore: Right-click on the database → Tools → Restore Database → Choose the example.sql script
A window to show errors

Include any warning/errors/backtraces from the logs

I fixed this error by following this step . Unistall Dbeaver . Go to C:\Users(your computer username)\AppData\Roaming\    delete dbever here . Now Install again Dbeaver but this time before you connect to mysql test your connection first. This will dowload some jdk . or java file something to your dbeaver . After you test the connection and its ok . Connect your mysql now to dbeaver. After this step you should fine in restoring and dumping mysql database.


Download excel from url and parse it, there is an error, it looks like the file is garbled

Is there any documentation or examples for reference?

Thanks for your feedback. Could you follow the issue template, and show us a complete, standalone example program or reproducible demo?

It seems still not have enough info of code and attachments to reproduce this issue, so I'll close this issue, if you have any questions, please let me know to reopen this anytime. Please also reference the example in the documentation about read data stream from io.Reader and return a populated spreadsheet file.


stream: use static dispatch for CodedInputStream

This pr use static dispatch for CodedInputStream. According to the perf test, there are some significant improvements in various cases.
master:
test1: write: 77 ns per iter
test1: read: 97 ns per iter
test1: read reuse: 92 ns per iter
test_repeated_bool: write: 69 ns per iter
test_repeated_bool: read: 165 ns per iter
test_repeated_bool: read reuse: 125 ns per iter
test_repeated_packed_int32: write: 102 ns per iter
test_repeated_packed_int32: read: 217 ns per iter
test_repeated_packed_int32: read reuse: 165 ns per iter
test_repeated_messages: write: 235 ns per iter
test_repeated_messages: read: 1171 ns per iter
test_repeated_messages: read reuse: 327 ns per iter
test_optional_messages: write: 205 ns per iter
test_optional_messages: read: 535 ns per iter
test_optional_messages: read reuse: 325 ns per iter
test_strings: write: 118 ns per iter
test_strings: read: 376 ns per iter
test_strings: read reuse: 172 ns per iter
test_small_bytearrays: write: 274 ns per iter
test_small_bytearrays: read: 251 ns per iter
test_small_bytearrays: read reuse: 130 ns per iter
test_large_bytearrays: write: 20139 ns per iter
test_large_bytearrays: read: 10893 ns per iter
test_large_bytearrays: read reuse: 7678 ns per iter
opt-is:
test1: write: 78 ns per iter
test1: read: 59 ns per iter
test1: read reuse: 52 ns per iter
test_repeated_bool: write: 86 ns per iter
test_repeated_bool: read: 114 ns per iter
test_repeated_bool: read reuse: 65 ns per iter
test_repeated_packed_int32: write: 134 ns per iter
test_repeated_packed_int32: read: 134 ns per iter
test_repeated_packed_int32: read reuse: 71 ns per iter
test_repeated_messages: write: 199 ns per iter
test_repeated_messages: read: 1003 ns per iter
test_repeated_messages: read reuse: 166 ns per iter
test_optional_messages: write: 190 ns per iter
test_optional_messages: read: 362 ns per iter
test_optional_messages: read reuse: 165 ns per iter
test_strings: write: 123 ns per iter
test_strings: read: 246 ns per iter
test_strings: read reuse: 109 ns per iter
test_small_bytearrays: write: 259 ns per iter
test_small_bytearrays: read: 219 ns per iter
test_small_bytearrays: read reuse: 93 ns per iter
test_large_bytearrays: write: 19579 ns per iter
test_large_bytearrays: read: 12098 ns per iter
test_large_bytearrays: read reuse: 6702 ns per iter
This pr break Message into Message and CodedMessage, which will require users to use CodedMessage explicitly once they upgrade protobuf. Old generated code will not work if this pr is merged.
I have no idea what format rules this project follows, so I haven't formatted the code yet, any suggestions?
I also changed CodedOutputStream to static dispatch too, but it's not included in the pr, because I see performance decrease in some cases. I will fire another pr once I figure it out.

I think there is too much noise in tests. You patch didn't modify write code, however, test results for write also change. E. g.
test_repeated_bool: write: 69 ns per iter
test_repeated_bool: write: 86 ns per iter

test_repeated_packed_int32: write: 102 ns per iter
test_repeated_packed_int32: write: 134 ns per iter

test_repeated_messages: write: 235 ns per iter
test_repeated_messages: write: 199 ns per iter

test_optional_messages: write: 205 ns per iter
test_optional_messages: write: 190 ns per iter

test_small_bytearrays: write: 274 ns per iter
test_small_bytearrays: write: 259 ns per iter

I don't believe dynamic dispatching is the main performance issue, and performance improvements should be significant to compilate API for users.

I can see the performance increase constantly when running the perftest repeatedly. You should also be able to reproduce it on your machine.
According to our own bench of a product, which does a lot of protobuf encode and decode and CPU is the bottleneck, performance increases about 15% after switching to the static dispatch branch.

I think parsing could be implemented efficiently without making dispatching static, but with a bit of unsafe code.
CodedInputStream could cache result of InputSource.fill_buf in a field.
This approach has two drawbacks:

You need unsafe code, because you cannot safely store fill_buf result in a field.

It is practially safe for BufRead and &[u8] param, because they are unmovable, because CodedInputStream holds a reference to that class.
It is practically safe for InputSource::Read(BufReader<&'a mut Read>) variant, because
** we know that BufReader buffer is not moved when BufReader is moved
** or alternatively, we can allocate BufReader in a box
** or we can have own implementation of BufReader.

User API will need something like flush() operation that would call consume on the underlying buffer in case CodedInputStream created from BufRead. This operation could be called from CodedInputStream destructor, but it is still a breaking change and a couple of client projects could be broken.

I think static dispatch way is more clean and elegant. When using static dispatch, the compiler figures out more possible improvements and handles all the inline and opt out things automatically. And the magic happens safely.
I personally don't think it's a good idea to keep a buffer inside library. I think it's caller's choices to choose buffer or not. Usually the Reader/Writer itself includes a buffer already.

I think static dispatch way is more clean and elegant.

It makes API harder to use, slows down compilation and increases binary size.

I personally don't think it's a good idea to keep a buffer inside library. I think it's caller's choices to choose buffer or not. Usually the Reader/Writer itself includes a buffer already.

In that case you can call CodedInputStream::from_buffered_reader and protobuf won't allocate own buffer. CodedInputStream will just store result of fill_buf, a pointer to the buffer.

It makes API harder to use, ...

Actually, after the changes, users only need to include CodedMessage trait, all the other things are the same as it used to be.

Reads do not (usually) call virtual functions now: f7dc5f02ddb5eeec16a0a933f8a6071dd98778a3.
I did as I proposed in my previous message. Although implementation now contains unsafe code and relies on BufReader implementation details, I think it is OK.

@stepancheg
Can we use the same unsafe way to handle CodedOutputStream?

@siddontang CodedOutputStream has no issue with virtual dispatch, because CodedOutputStream is buffered. However, it has an issue with double-buffering.
I assume that CodedOutputStream needs access to write buffer for performance. So we have four cases then:

underlying Write is not buffered. Everything's right, CodedOutputStream does the buffering.
underlying Write is actually a wrapper around around [u8], which writes to that area. This issue needs to be fixed by adding another constructor in CodedOutputStream which should accept &[u8] and use it as buffer (with a bit of unsafe code).
underlying Write is buffered and written message is large (say, 100K). Is not an issue, because BufWriter (and probably other implementations of buffered writers) skips internal buffering on large writes.
underlying Write is buffered and written data is small (e. g. 1K). There's nothing can be done here, because Rust has no BufWrite trait, and even BufWriter (unlike BufRead) does not provide access to its buffer.

CodedOutputStream::bytes constructor is added in 035d82c80bdbfb55ecdfae97c7a321620e267842.

CodedOutputStream::vec constructor added:<PHONE_NUMBER>e7ceb5efca1ffb3ea3421f79e83356.

I assume that CodedOutputStream needs access to write buffer for performance.

Could you elaborate on this assumption?  CodedOutputStream does not currently make use of the interior buffer, but maybe you have something as-of-yet unimplemented in mind.
The biggest performance issue I've run into with this library is the overhead of the internal buffering in CodedOutputStream.  By removing the internal buffering, rust-protobuf can be more performant and easier to use, as prototyped in #199 .

Hi @danburkert
@stepancheg supplies a bytes and vec constructors which don't create the internal buffer and I think it is better to keep the API backward compatibility.
Can we use another ButWriter trait to fix the underlying Write is buffered case?

@stepancheg supplies a bytes and vec constructors which don't create the internal buffer and I think it is better to keep the API backward compatibility.

The vec constructor does create an internal buffer, the Vec.  The bytes constructor is better, but it's not quite as ergonomic as serializing directly to a Write instance.  It also doesn't work for cases where you are trying to write to non-contiguous buffers.

Can we use another ButWriter trait to fix the underlying Write is buffered case?

Why?  What's the problem with just writing directly to a Write?

Hi @danburkert

Why? What's the problem with just writing directly to a Write?

I guess @stepancheg doesn't want to break the API, so I think maybe we can supply other construct functions.

@danburkert

The vec constructor does create an internal buffer, the Vec.

Not it doesn't. It uses Vec provided by user, and CodedOutputStream.buffer is a reference to that Vec data.

@siddontang

Can we use another ButWriter trait to fix the underlying Write is buffered case?

Something similar to BufRead trait:
trait BufWrite : Write {
    fn buffer(&mut self) -> &mut [u8];
    fn commit(&mut self, amount: usize) -> io::Result<()>;
}

It could be added to the rust-protobuf, but user would need to implement it.

Why? What's the problem with just writing directly to a Write?

I think writing directly to byte array can be faster that writing to Write byte at a time (for example, when you writing varint which can be 1 to 10 bytes long.
This is how it is done in Java and C++ implementations of protobuf: if you know that buffer has at least 10 bytes available (it is true most of the time), that you can write directly to that array, otherwise you need to do a sequence of single byte writes, or create a 10 bytes array on the stack, write to it and then write that array to the Write performing unnecessary copying and a loop.
Rust-protobuf doesn't have this optimization, but it should.

Not it doesn't. It uses Vec provided by user, and CodedOutputStream.buffer is a reference to that Vec data.

OK fair enough.  The issue is, however, that only helps if the application is trying to serialize into a Vec. In my case I want to serialize into a netbuf buffer, and many applications using mio/tokio often want to serialize into a bytes buffer.  In general, you are never going to be able to add a variant for all of the different buffer abstractions.  That's exactly why the Write abstraction exists.

create a 10 bytes array on the stack, write to it and then write that array to the Write performing unnecessary copying and a loop.

That sounds like a great optimization to me, the extra copy of up to 10 bytes from a stack allocated array is going to be extremely cheap (as opposed to having to copy all strings and variable length fields again, as I would currently have to do to serialize into a netbuf).  Not sure what you mean by an extra loop.
If cutting out that small copy for varints is really that important, then I think it can still be done by specializing the CodedOutputStream trait for Vec or maybe AsMut<[u8]>.

Or, even more simply, do an initial check to see if the varint can be serialized to 1 byte, and if so do it directly.  I imagine most varint serialization is done for tags, and most tags are done in a single byte.

@danburkert

extra copy of up to 10 bytes from a stack allocated array is going to be extremely cheap

It is extremly cheap, but extremely frequent.

even more simply, do an initial check to see if the varint can be serialized to 1 byte, and if so do it directly. I imagine most varint serialization is done for tags, and most tags are done in a single byte.

It depends on your data. Sometimes you have integer fields (e. g. enums). Every message or string starts with varints. Sometimes you have fields with numbers above 16, so tags occupy more than one byte.

Not sure what you mean by an extra loop.

memcpy within buffered Write implementation after a loop which populates 10-bytes buffer.

That's exactly why the Write abstraction exists.

No, that's why abstractions like ZeroCopyOutputStream exist. Rust standard library provides no such abstraction.
But as I said earlier, BufWrite abstraction could be added to rust-protobuf. So BufWrite could be implemented for bytes and netbuf (and for Vec).
Will that work for you?

I think we're at an impasse.  If you aren't willing to break backwards compat I'll continue maintaining a fork.

@danburkert

I think we're at an impasse.  If you aren't willing to break backwards compat I'll continue maintaining a fork.

Could you be a little more constructive, please?
I've proposed a solution: BufWrite trait. Will it work for you? If it won't could you please explain why?
If it won't, probably we will think of something else.
It is a backward compatibility issues, but I also honestly think that current state of CodedOutputStream is the best API choice even if project started from scratch. Because of its simplicity: you do not need to make every function generic.

Sure,
For BufWrite to work it would need to be in the standard library.  Otherwise it's unreasonable to expect the netbuf or any other buffer abstraction crate to implement it.  Likewise, it's unreasonable to expect you to implement it for every odd buffer abstraction out there.  As a consumer of netbuf and protobuf, my application can't implement it due to coherence rules.
Secondly, BufWrite isn't (and probably never will be) in the stdlib because it's a poor abstraction when combined with the safety guarantees that Rust likes to provide.  To implement it, buffers would need to fully initialize returned memory, which makes the abstraction useless because the extra memset negates the advantages of cutting out a memcpy.

I also honestly think that current state of CodedOutputStream is the best API choice even if project started from scratch. Because of its simplicity: you do not need to make every function generic.

Have you read #199?  The API is simpler than the current API.  For example, the awkward with_coded_output_stream function is no longer needed and has been removed. The API now works with any Write instance, no need to wrap it in a CodedOutputStream as an intermediate step.  It stops the proliferation of write_to_<blah> functions.
With regards to making serialization methods on Message take a type param - I agree with you.  It's important to me that Message remains object-safe, so type params can't be used.  #199 doesn't change that.

The type params on ProtobufType can be changed back to trait objects; that was an oversight in the PR.

@danburkert

The type params on ProtobufType can be changed back to trait objects; that was an oversight in the PR.

If that was an oversight, could you please fix that PR to avoid misunderstanding?

Sure, I can do that in the next few days.

I assume that static dispatching is no longer necessary, because CodedInputStream caches result of BufWriter.write. So I'm closing the issue.


'cargo vendor' seems non-deterministic

In Cargo.toml files generated by cargo vendor, the order of dependencies seems not to be deterministic: when updating in Firefox a crate to a version that did not change the set of dependencies, I get a diff like below.
Could this be based on the iteration order of a HashMap that uses the default RandomState hasher? If so, what do you think of switching to a deterministic hasher? Or perhaps sorting before generating TOML files?
diff --git a/third_party/rust/cssparser/Cargo.toml b/third_party/rust/cssparser/Cargo.toml
index 76fadfd855e4..94e9f473274c 100644
--- a/third_party/rust/cssparser/Cargo.toml
+++ b/third_party/rust/cssparser/Cargo.toml
@@ -12,7 +12,7 @@

 [package]
 name = "cssparser"
-version = "0.18.0"
+version = "0.18.1"
 authors = ["Simon Sapin<EMAIL_ADDRESS> build = "build.rs"
 exclude = ["src/css-parsing-tests/**", "src/big-data-url.css"]
@@ -22,33 +22,33 @@ readme = "README.md"
 keywords = ["css", "syntax", "parser"]
 license = "MPL-2.0"
 repository = "https://github.com/servo/rust-cssparser"
-[dependencies.heapsize]
-version = ">= 0.3, < 0.5"
-optional = true
-
 [dependencies.serde]
 version = "1.0"
 optional = true

+[dependencies.heapsize]
+version = ">= 0.3, < 0.5"
+optional = true
+
 [dependencies.procedural-masquerade]
 version = "0.1"

-[dependencies.cssparser-macros]
-version = "0.3"
-
 [dependencies.matches]
 version = "0.1"

 [dependencies.phf]
 version = "0.7"
-[dev-dependencies.encoding_rs]
-version = "0.5"
+
+[dependencies.cssparser-macros]
+version = "0.3"
+[dev-dependencies.rustc-serialize]
+version = "0.3"

 [dev-dependencies.difference]
 version = "1.0"

-[dev-dependencies.rustc-serialize]
-version = "0.3"
+[dev-dependencies.encoding_rs]
+version = "0.5"
 [build-dependencies.syn]
 version = "0.11"

Hm in theory cargo vendor should be deterministic. It looks like this is oscillating between 0.18.0 and 0.18.1, do you know why that might be happening?

This was a changeset where I ran cargo update -p cssparser to update from 0.18.0 to 0.18.1, then ran mach vendor rust which calls cargo vendor. The change to the version line is expected, the changes to dependencies.* and dev-dependencies.* are not.

Aha it does indeed appear that the 0.18.0 to 0.18.1 transition didn't change Cargo.toml so this manifest was produced by this function which I believe does include hash map iteration.

It looks like the TomlManifest struct contains hash maps, and serde is responsible for (iterating them and) serializing them to TOML. So there is no place where a .collect::<Vec<_>>() and .sort() could be easily added.
So what do you think of using BuildHasherDefault<DefaultHasher> (which despite the name is not HashMap’s default) instead of the default RandomState, in these maps?

Or using BTreeMap, to sort by key rather than some arbitrary ordering?

I think it'd be fine to just change those to BTreeMap

I was wrong, it’s not cargo vendor but cargo package that re-serializes Cargo.toml.


Something is missing : How to registrer the Microsoft.AzureData provider ?

If we follow prerequisite then the deployment guide, we get the following message :
New-AzResource : MissingSubscriptionRegistration : The subscription is not registered to use namespace 'Microsoft.AzureData'. See https://aka.ms/rps-not-found for how to register subscriptions.
so you should add a step to register Microsoft.AzureData resource provider
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 2b9f51bd-1ce7-dcbb-6d42-3ec6e51e0e23
Version Independent ID: 299a7dc8-b9b2-503d-6a24-0da0e2b48dd8
Content: Azure Arc enabled SQL Server
Content Source: docs/sql-server/azure-arc/overview.md
Product: sql
GitHub Login: @anosov1960
Microsoft Alias: sashan

@squasta -- Stanislas, thank you for your feedback.  Please consider these resources:

SQL Server on Microsoft Q&A
DBA Stack Exchange
Stack Overflow

@anosov1960 -- Alexander, please look into this issue.

It is documented in https://docs.microsoft.com/sql/sql-server/azure-arc/connect#prerequisites

#please-close


chore(*): Initial setup of CODEOWNERS file (automatic review assignments)

Small PR to setup an initial GitHub CODEOWNERS file.
Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. Code owners are not automatically requested to review draft pull requests.
I've added the following rules for now;

when any markdown (*.md) file is modified, request review from @rachelsaunders
when any package.json or lerna.json file is modified, request review from myself and @Ehesp
when any of the new testing files/setup are modified, request review from myself and @Ehesp

Hope these initial ones are ok? I can add more specific to each extension if required - let me know :)

LGTM

Didn't get a chance to review this CL before it was merged.  Could we please do the following:

add extension.yaml to the files that auto-add rachelsaunders as a reviewer
add the reviewer of annie-ryan to all the same files and file types that rachelsaunders is auto-added to?

@rachelsaunders sure, will send another PR


[Feature request] More pronouced info about wrong placement of ticks

When I was executing python code I had in one chunk a ticks moved by one space
My wrong code
 ```{python}
#| label: chunkA

x = 2
```
```{python}
#| label: chunkB
print(x)
```

giving the output
Executing 'test.ipynb'
  Cell 1/1...ERROR:

An error occurred while executing the following cell:
------------------
print(x)
------------------

---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
Cell In [1], line 1
----> 1 print(x)

NameError: name 'x' is not defined
NameError: name 'x' is not defined

The code should be written
```{python}
x = 2
```
```{python}
print(x)
```

In the first case the variable x is unavailable  int the s B chunk when rendering.
Would be great if there would some better  mechanism informing the  about the  the wrong placement of ticks in the first case or the first case  ticks shouldn't render as a proper chunk

One problem is that whitespace is technically allowed before the ticks in some cases (e.g. lists). In your case the ticks are unambiguously not doing what is intended but I think our regex isn't appreciating the nuance! We will try to make this better, thanks for reporting.


Release v1.21.0 Engineering Management

As a [user role below]:
Release manager

I need to:
create a release branch, one or multiple release candidates, and the final v1.21.0 release of Carbon for IBM.com

so that I can:
release the next version of Carbon for IBM.com to the public

Additional information

Release Management Playlist: https://ibm.ent.box.com/notes/497596874716
Release Plan/Pinned issue: https://github.com/carbon-design-system/carbon-for-ibm-dotcom/issues/5888
Full release changelog should compare to v1.20.0

Acceptance criteria

[ ] Release branch created per timeline
[ ] v1.21.0 of Carbon for IBM.com released per timeline

@RobertaJHahn v1.21.0 release has been completed!


Mouse Scrolling

Hi,
I have one simple question: For mouse input i use a gainput::InputDeviceMouse object and id didn't find out, how to capture mouse scrolling (i work on Windows 7). I initialized the InputDeviceMouse  with
gainput::InputDevice::AutoIndex and gainput::InputDevice::DV_STANDARD, as with gainput::InputDevice::DV_RAW it didn't work, at all (no mouse input was registered). As a next step i tested all mouse buttons, but no one did the wished result.
So: How is it possible to capture mouse scrolling?

Mouse scrolling is represented as boolean buttons. That means the buttons gainput::MouseButtonWheelUp and gainput::MouseButtonWheelDown will be down for one frame if the user is using the scroll wheel on the mouse. That means if you call gainput::InputDevice::GetBool(gainput::MouseButtonWheelUp) on a mouse device it should return true for exactly one frame.
Does that help?

Unfortunately, no it doesn't help. My first approach was to use a gainput::InputMap to map my own enum to the scroll wheel, but your tip doesn't work ever. Left, right and middle mouse buttons work just fine, but it seems to me, that the  WM_MOUSEWHEEL message isn't properly handled. At least i know, that this message is sent to the gainput::InputManager via gainput::InputManager::handleMessage().


[WIP] nix-flakes etude

Summary
Generates a basic flake.nix file that can be used with nix develop.

[ ] understand how flakes and nix-profile work together
[ ] figure out story for adding to git (or not)
[ ] shell environment and prompt doesn't seem to be getting set

How was it tested?
> cd testdata/rust/rust-stable

# See TODO around managing this git add
> git add flake.nix

> nix develop

> ➜ nix develop
Starting a devbox shell...
Savil-Srivastavas-MacBook-Pro:rust-stable savil$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/hello-rust`
Installed version is 1.61.0
thread 'main' panicked at 'Version 1.61.0 is less than expected version of 1.63.0', src/main.rs:11:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This failure is somewhat expected. It arises because we are (likely) getting the stable
nix channel. That likely has the older version of rustup.

Current dependencies on/for this PR:

main

PR #247   👈

This comment was auto-generated by Graphite.


Update engine-based services

I'd like to have the changelog reviewed by @eduardolundgren or @igr, because we mention what changed in the engine-base image

engine-based is an unknown entity by the users, therefore we should focus on the change itself.

Just started reviewing :) :octocat: Sent from GH.


Is recommended practice to get_current_tenant for every view?

The docs state that:
Set the tenant using set_current_tenant(t) api in all the views which you want to be scoped based on tenant.
Does this mean that the recommended approach is to store the current tenant in a cookie (session variable) and then call it for each and every view that is rendered?
When simply setting the variable it appears to persist between views in thread local storage. Is this discouraged? Why otherwise incur the extra overhead of accessing session variables in every view?

Hi @rob101,
Are you using django-multitenant with citus, or with single node postgres? You could store it in a session variable, or if you have a logged in user with the tenant column, you could use that instead of the cookie.
In general we tend to recommend using a Middleware that would set the current tenant, rather than actually set it in all views you want it to be. But it would still be called for every call. What is your thought around this? Did you want to set it only in a login view>

Hi @louiseGrandjonc, sorry for the late reply (I missed this). I am using postgres. My use case actually allows users to switch tenants, so my thought is to set it in a session variable via middleware as you suggest:
class TenantMiddleware:
    """
    If tenant_pk is stored in the current session, for each view set the
    issuer object as the tenant, and store the object in request.tenant.
    """

    def __init__(self, get_response):
        self.get_response = get_response
        # One-time configuration and initialization.

    def __call__(self, request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.

        # Get the issuer stored in the session (set via issuer_select)
        session_tenant = get_tenant_from_session(request)

        # Get the current issuer object that is set as current tenant
        tenant= get_current_tenant()

        # Make the current tenant available as request.issuer
        request.tenant = tenant

        # If the issuer has changed, update the tenant object
        if session_tenant != tenant:
            set_current_tenant(tenant)
            request.tenant = session_tenant

        return self.get_response(request)

I also defined a session tenant helper:
    def get_issuer_from_session(request):
    """
    Return the Tenant object from the current session
    """
    tenant_pk = request.session.get('tenant_pk', None)

    try:
        tenant= MyTenantModel.objects.get(pk=tenant_pk)
    except MyTenantModel.DoesNotExist:
        tenant = None

    return tenant

What do you think?


Add improvements about Plone 4 training

Fixed some gettext files errors.

Updated Gettext files.

Updated Integration with Transifex https://www.transifex.com/plone/plone4-training/

Updated Spanish translation files.

@macagua feel free to merge this yourself when it'ready. Please note that the travis-build will always fails when you use a fork, you might want to use a branch instead.
We're no longer maintaining the Plone 4 training since it is helplessly behind the Plone 5 version and does not contain any of the additional trainings that are on https://training.plone.org/5/

Also I strongly believe that new developers should learn (and work with) Plone 5 and not Plone 4. I consider working with legacy-code a job for advanced developers.

@pbauer thanks you for response!
I made a fork for create a pull request following the contributing guide:

Plone 4 https://training.plone.org/4/about.html#contributing

But should this new procedure, should be be reflected in the contribution guide for Plone 4 and Plone 5?, right?

Plone 5 https://training.plone.org/5/mastering_plone/about_mastering.html#contributing

If I use a branch to add new improvements about the docs, then I a create a new branch for example plone4_new_feature, add the new improvements and merge it fron the plone4_new_feature branch to plone4 branch, right?

@pbauer About promoting the training of Plone 5 over Plone 4, I agree with you, only that since 2012, we have maintained the translation of Plone 4 from Conectivo R.L. (my company), it was time to share it with the community. Check out the following link:
https://www.transifex.com/plone/plone4-training/translate/#es
In addition the work of the translations of the training of Plone 4, is reusable to feed the minorities of translation of the version of Plone 5 in the platform Transifex.
https://www.transifex.com/plone/plone5-training/translate/#es
Because the translations made for the Plone 4 version are suggested as Plone's LiveSearch functionality, which recommends which element matched your search criteria including a percentage of accuracy, well these previous translations appear as a suggested translation previously performed, This streamlines translation processes, as well as standardizing the terms used for translation.
Also, we (some Plonistas from Venezuela) started the Spanihs translation of Plone 5 training resources, based on the translations made for Plone 4 training resources, I hope to make a pull request with new translations in this case for Plone 5.


(Imp) Add these items in app if missing

Please open the link
https://docs.google.com/document/d/1IzzI3VOo27mBKR6vsrHQ43t93xzsQ1o4wyKksmcT_ak/edit?usp=sharing

Please find the schema here for data types, it may be useful https://github.com/covenantproject/cov-backend/blob/master/docs/Covenant-db-release1-schema-v1-doc.html


Add monolith to microservices book

Hacktoberfest notes:

due to volume of submissions, we may not be able to review PRs that do not pass tests and do not have informative titles.
please read our contributing guidelines
be sure to check the output of Travis-CI for linter errors
if this is your first open source contribution, make sure it's not your last!

What does this PR do?
Add an ebook about microservices
For resources
Description
A practical guide from O’Reilly and NGINX to cover scenarios and strategies for a successful migration from a monolithic system to a microservices architecture.
Why is this valuable (or not)?
It provides strategies how to migrate from a monolith architecture to microservices.
How do we know it's really free?
It's in Nginx website
For book lists, is it a book? For course lists, is it a course? etc.
It's a book.
Checklist:

[x] Not a duplicate
[x] Included author(s) if appropriate
[x] Lists are in alphabetical order
[x] Needed indications added (PDF, access notes, under construction)

email REQUIRED


Same Path Error

When I tried to use extension  following error occurred.

Hello, I'm linking my comment from another closed issue. Could you please confirm if the solution I provided solves your issue?
https://github.com/ElecTreeFrying/drag-import-relative-path/issues/4#issuecomment-1483869115

Thank you for raising this concern. I understand your point, but based on the accompanying .gif, it appears that the behavior is intended and not a bug. To successfully drag a file, please ensure that the file is selected in the tree view as shown in the .gif. If you have any further questions or issues, feel free to ask.
If there are no further replies within a week, we will close this issue, assuming it's resolved. Thank you.

Hi, i have the same problem. But i cannot select the files(left click) from the tree-view because they are directly opened...
How can this extension been used anyway?
Best regards

Closing this issue as a duplicate of #4. Please refer to the original discussion for further comments and updates. Thanks


[Folding] CSS/Less/SCSS Regions Don't Work With Syntax Aware Folding

Issue Type: Bug
Adding /* #region */ and /* #endregion */  markers to CSS, Less, or SCSS files does not enable folding for those regions.
This only applies when "editor.foldingStrategy" is set to "auto". When it is changed to "indentation", folding works as expected.

Reproduced with all extensions disabled.
VS Code version: Code 1.22.2 (3aeede733d9a3098f7b4bdc1f66b63b0f48c1ef9, 2018-04-12T17:28:16.777Z)
OS version: Windows_NT ia32 10.0.16299

https://github.com/Microsoft/vscode/issues/46591 already available in insider. Use https://code.visualstudio.com/insiders/ or wait for next month's release.


Memory Game to JS Mini Project

Describe the project you want to add with tech stack
HTML, Javascript
can be seen here:
https://github.com/Paulie-Aditya/js-games/tree/main/memory-game

Please do assign this to me if it interests you

is it same as this?
If yes, maintain the high quality standards while implementation


MacOS supported versions (Catalyst)

There's a statement on the supported platforms page: "macOS 10.13 or higher (using Mac Catalyst)".
But this is confusing, since Mac Catalyst support was added since version macOS 10.15. I may be wrong about this, but to my understanding macOS versions prior to 10.15 Catalina don't support Catalyst?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6fb754bf-48db-4f6c-7e87-7cb3b59c34d5
Version Independent ID: ba07354c-611d-5efe-0fbb-48a24d02cafe
Content: .NET MAUI supported platforms - .NET MAUI
Content Source: docs/supported-platforms.md
Product: dotnet-mobile
Technology: dotnet-maui
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Hello @asymala I'm going through issue we may have missed and found yours. What you pointed out, sounds correct. @Redth would you be able to confirm that minimum OS requirements for both running a .NET MAUI app and developing a .NET MAUI app for mac?


changed link to extension-ideas repository

@ajeetsraina How can we change the "Submit Your Docker Extensions" link 👇?

@ivan-curkovic You need to edit default.html file under https://github.com/collabnix/docker-community-extensions/blob/main/_layouts/

@ivan-curkovic I will fix it for you.

Thanks @ajeetraina


Deploy Microsoft Store page version correction

Learn Build status updates of commit d2b3257:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sysinternals/downloads/microsoft-store.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel


Training simple_object_detector in Python and then loading it in C++ problem

I'm training a simple_object_detector using dlib's Python API:
options = dlib.simple_object_detector_training_options()
options.add_left_right_image_flips = False
options.C = 5
options.num_threads = 3
options.be_verbose = True

dlib.train_simple_object_detector("data.xml", "detector.svm", options)

If I then load this detector in Python using dlib.simple_object_detector("detector.svm") and try to evaluate it on a dataset, it works really really well. The problem is that we need to use the detector in C++, and there it barely works.
The detector.svm is loaded like this in C++:
typedef scan_fhog_pyramid<pyramid_down<6> > image_scanner_type;
image_scanner_type scanner;

object_detector<image_scanner_type> detector;
deserialize("face_detector.svm") >> detector;

It only works on very few of our test images (like 5 out of 100), whereas in Python we get most of them correctly (like 90-95 out of 100). I assume that the .svm file is not loaded correctly in C++.
If I load the .svm file in Python using dlib.fhog_object_detector("detector.svm"), then I actually get the same behaviour as in C++: It only works for the same 5 images. But this is a bit confusing, because the detector wasn't trained as an fhog object detector, but the method also doesn't throw an error.
There is another weird behaviour: The bounding box found in C++ seems to be different from the one found in Python. Here's the bounding box we get for one of the test images in Python:

And here is the bounding box generated by the exact same .svm file in C++ (The screenshot is a bit bigger, but of course both programs run on the same image):

It seems like in C++ the detector tries a much larger sliding window, and therefore doesn't find any objects if they are smaller.
This is the C++ code that's being used for giving the OpenCV image to the dlib detector:
cv::Mat imgForDlib = cv_ptr->image.clone();
dlib::cv_image<dblib::bgr_pixel> cimg(imgForDlib);
std::vector<dlib::rectangle> objects = detector(cimg);

Is that detector not loaded correctly in C++? Or is it a problem with the image datatype that we give to dlib?
We would greatly appreciate any help!

In the Python training part this is printed after training is done:
Trained with sliding window 82 pixels wide by 78 pixels tall.
Upsampled images 2 times to allow detection of small boxes.

I'm not sure if this helps with the issue. Does this mean that the 6 in pyramid_down<6> is wrong?

It's fine.  You are just upsampling the images in python before processing but not in C++.  Upsample the images in C++ before giving them to the detector.

Thanks a lot for the quick reply!
Do you mean just calling pyramid_up(cimg)? How often does this method need to be called to have the same upsampling as in Python?
Is there any good way to call this method when working with OpenCV images?

Yes, that's what I mean.  How much depends on what the python code did.  That message you posted makes it sound like you should call it 2 times.
If you want to use OpenCV things you should look at the OpenCV documentation.

Great, thanks! That seems to have improved things.
The bounding box is now off, I guess this is because we upsampled the image.
Sorry if this is another very simple question, but by how much does pyramid_up increase the image size? It seems to be image dependent, calling the method twice sometimes increases the width by 4.04, sometimes by 4.055. I searched for a while but didn't find anything on this.

http://dlib.net/faq.html#Whereisthedocumentationforobjectfunction


Add env parameter to bazel_integration_test, remove "CC" passing

Following the discussion in #70 this PR adds env parameter to bazel_integration_test and removes passing CC=clang by default

FYI. If you run bazel run //:update_all, it should update the files with the properly formatted version.

FYI. If you run bazel run //:update_all, it should update the files with the properly formatted version.

Yep, I've just found it


intersects example/ STAREDataFrame.set_pixels inplace doesn't work.

This seems to work.
iceland.set_trixels(iceland.make_trixels(),inplace=True)

yes. This is the intended usage!


There hasn't been a change to openProcess. Yet, as you can see, you are missing a handle. Which is probably also the reason why openProcess fails

open_process(process: string|int,  debug: bool = false): Process
But just need to pass a process PID or process name, I can open it normally with 32-bit programs, some x64 programs don't work, and I use CE to see if the process has permission to be accessed

Sorry, I clicked the wrong button and opened a new question,
However, when I use ctypes to call the OpenProcess (0x1ffff, False, pid) API to open the same process, I can open the handle normally, which proves that the permissions are sufficient. In other words, I can also open the process using the previous pymeow. When I downloaded the latest pymeow, I found that there was no open process, so it was very strange

def __init__(self):
    self.pid = pyMeow.get_process_id('pycharm64.exe')
    self.Process = pyMeow.open_process(self.pid, debug=True)
    print(f"Process:{self.Process}")

Process:{'name': 'pycharm64.exe', 'pid': 83428, 'debug': True, 'base':<PHONE_NUMBER>, 'handle': 464}
for proc in pyMeow.enum_processes():
    print(proc)

{'name': 'DNF.exe', 'pid': 20852, 'debug': False, 'base': 0, 'handle': 0}
{'name': 'SGuardSvc64.exe', 'pid': 83512, 'debug': False, 'base': 0, 'handle': 0}
nimpy.Exception: Unexpected error encountered: Module 'DNF.exe' not found
At present, that's all I can provide. I'm not sure if this exception is caused by the process not being found or by the OpenProcess API

I have tested the get'module function with the previous version of PyMeow and it works fine. It can return the module address, but some methods may not work because I used the previous version. However, in the latest version, I cannot open the Process properly, so I cannot test the get'module method on the new PyMeow

I think I may not be able to compile. I used to download packaged pyd files, so can I just wait for qb's approval

Hint: used config file 'F:\nim-2.0.8\config\nim.cfg' [Conf]
Hint: used config file 'F:\nim-2.0.8\config\config.nims' [Conf]
........................................................................
Error: cannot open 'F:\nim-2.0.8\bin\pyMeow.nim'

I pulled down the latest code and recompiled pymeow, but still get the error self. Process=pyMeow. open_decess (self. pid, debug=True)
nimpy.Exception: Unexpected error encountered: Module 'DNF.exe' not found， Can I only use the old version of Pymeow now

def __init__(self):
    self.pid = pyMeow.get_process_id('DNF.exe')
    print('process_pid:', self.pid)
    self.Process = pyMeow.open_process(self.pid, debug=True)

process_pid: 79944
Traceback (most recent call last):
File "F:/Myproject/.vscode/x64rw.py", line 103, in
process = Memory()
File "F:/Myproject/.vscode/x64rw.py", line 15, in init
self.Process = pyMeow.open_process(self.pid, debug=True)
nimpy.Exception: Unexpected error encountered: Module 'DNF.exe' not found

@Hypnootika
proc getModule(process: Process, moduleName: string): Module {.exportpy: "get_module".} =
for module in enumModules(process):
echo module
if moduleName == module.name:
return module
echo "end found"
raise newException(ValueError, fmt"Module '{moduleName}' not found")
I made changes to the code locally and found that the echo module did not print anything. Instead, it threw an exception saying 'Module' {moduleName} 'not found before printing' end found '. Therefore, I suspect that there was an error in the for module in enum Modules (process): this error was caused by the program not going into the loop, and even when I pulled the latest code, it would still look like this

@Hypnootika
File "F:/Myproject/.vscode/pymeow_test/x64rw.py", line 35, in r_int
return pyMeow.r_int(self.Process, address)
nimpy.AccessViolationDefect: Unexpected error encountered: Read failed [Address: 0x000000014B9CE0A0] [Error: 5 - 拒绝访问。]
Process:{'name': 'DNF.exe', 'pid': 20392, 'debug': True, 'handle': 424}
I used the code in the fork (branch "patch-1"), and indeed did not use getModule. However, I seem to have encountered a new problem where I am encountering exceptions when applying for memory or retrieving module addresses. Please take a look again. Thank you very much, as I am not very familiar with the nim language, some questions may appear slightly inferior

444/10000
实时翻译
划译
It is normal for me to use these methods with a 32-bit process, but using my DNF.exe will return an empty list
self.pid = pyMeow.get_process_id('DNF.exe')
print('process_pid:', self.pid)
self.Process = pyMeow.open_process(self.pid, debug=True)
self.allow = pyMeow.allocate_memory(self.Process, 1024)
print(self.allow)
pyMeow.free_memory(self.Process,<PHONE_NUMBER>)
self.module = [x for x in pyM

It is normal for me to use these methods with a 32-bit process, but using my DNF.exe will return an empty list
def init(self):
self.pid = pyMeow.get_process_id('DNF.exe')
print('process_pid:', self.pid)
self.Process = pyMeow.open_process(self.pid, debug=True)
self.module = [x for x in pyMeow.enum_modules(self.Process)]
print(self.module)

It is normal for me to use these methods with a 32-bit process, but using my DNF.exe will return an empty list
def init(self):
self.pid = pyMeow.get_process_id('DNF.exe')
print('process_pid:', self.pid)
self.Process = pyMeow.open_process(self.pid, debug=True)
self.module = [x for x in pyMeow.enum_modules(self.Process)]
print(self.module)

I'm very sorry, I can use the pycharm64.exe process. I don't know what the problem is with my process, so I'm sorry to trouble you. Thank you very much. I'll just use the previous pymeow version

@Hypnootika
I'm glad I solved the problem because my process doesn't have read and write permissions. I loaded a driver to make it read and write, and it worked fine. Thank you very much. It seems that the branch version is missing a few functions
get_proc_address(moduleName,  functionName: string): uint
create_remote_thread(process: Process,  startAddress: uint, param: uint): bool
inject_library(process: Process,  dllPath: string): bool
By the way, I also want to ask a question. Can nim implement x64 calling conventions? Because some games' calls may require

It's already encapsulated in Pymeow, I don't think I saw it. How can I call it if I want to
I will close this issue later


Error in CI: Could not find a version that satisfies the requirement prelude-parser (from versions: none)

The following line in testing.yml is causing an error in the CI pipeline:
python -m pip install --no-index --find-links=dist/ prelude-parser

I was unable to determine the purpose of this command, so I removed it for now. After doing so, linting ran successfully.
Please see the log below for more details:
See the log below:

Log
```
2024-09-18T06:24:13.4603437Z Current runner version: '2.319.1'
2024-09-18T06:24:13.4629356Z ##[group]Operating System
2024-09-18T06:24:13.4630009Z Ubuntu
2024-09-18T06:24:13.4630474Z 22.04.5
2024-09-18T06:24:13.4630775Z LTS
2024-09-18T06:24:13.4631112Z ##[endgroup]
2024-09-18T06:24:13.4631574Z ##[group]Runner Image
2024-09-18T06:24:13.4632167Z Image: ubuntu-22.04
2024-09-18T06:24:13.4632578Z Version: 20240915.1.0
2024-09-18T06:24:13.4633656Z Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20240915.1/images/ubuntu/Ubuntu2204-Readme.md
2024-09-18T06:24:13.4635118Z Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240915.1
2024-09-18T06:24:13.4635942Z ##[endgroup]
2024-09-18T06:24:13.4636420Z ##[group]Runner Image Provisioner
2024-09-18T06:24:13.4636898Z 2.0.384.1
2024-09-18T06:24:13.4637222Z ##[endgroup]
2024-09-18T06:24:13.4652714Z ##[group]GITHUB_TOKEN Permissions
2024-09-18T06:24:13.4654417Z Contents: read
2024-09-18T06:24:13.4654860Z Metadata: read
2024-09-18T06:24:13.4655391Z Packages: read
2024-09-18T06:24:13.4655937Z ##[endgroup]
2024-09-18T06:24:13.4658957Z Secret source: Actions
2024-09-18T06:24:13.4659638Z Prepare workflow directory
2024-09-18T06:24:13.5410432Z Prepare all required actions
2024-09-18T06:24:13.5571769Z Getting action download info
2024-09-18T06:24:13.7577916Z Download action repository 'actions/checkout@v4' (SHA:692973e3d937129bcbf40652eb9f2f61becf3332)
2024-09-18T06:24:13.8642846Z Download action repository 'actions/setup-python@v5' (SHA:f677139bbe7f9c59b41e40162b753c062f5d49a3)
2024-09-18T06:24:14.0889928Z Complete job name: python-linting
2024-09-18T06:24:14.1838748Z ##[group]Run actions/checkout@v4
2024-09-18T06:24:14.1839454Z with:
2024-09-18T06:24:14.1839860Z   repository: apcamargo/pydustmasker
2024-09-18T06:24:14.1840577Z   token: ***
2024-09-18T06:24:14.1841065Z   ssh-strict: true
2024-09-18T06:24:14.1841459Z   ssh-user: git
2024-09-18T06:24:14.1841826Z   persist-credentials: true
2024-09-18T06:24:14.1842621Z   clean: true
2024-09-18T06:24:14.1843030Z   sparse-checkout-cone-mode: true
2024-09-18T06:24:14.1843516Z   fetch-depth: 1
2024-09-18T06:24:14.1843974Z   fetch-tags: false
2024-09-18T06:24:14.1844378Z   show-progress: true
2024-09-18T06:24:14.1844742Z   lfs: false
2024-09-18T06:24:14.1845168Z   submodules: false
2024-09-18T06:24:14.1845571Z   set-safe-directory: true
2024-09-18T06:24:14.1845967Z env:
2024-09-18T06:24:14.1846387Z   CARGO_TERM_COLOR: always
2024-09-18T06:24:14.1846827Z   RUST_BACKTRACE: 1
2024-09-18T06:24:14.1847210Z   RUSTFLAGS: -D warnings
2024-09-18T06:24:14.1847691Z   PYTHON_VERSION: 3.9
2024-09-18T06:24:14.1848189Z ##[endgroup]
2024-09-18T06:24:14.3723397Z Syncing repository: apcamargo/pydustmasker
2024-09-18T06:24:14.3725535Z ##[group]Getting Git version info
2024-09-18T06:24:14.3726471Z Working directory is '/home/runner/work/pydustmasker/pydustmasker'
2024-09-18T06:24:14.3727657Z [command]/usr/bin/git version
2024-09-18T06:24:14.3766115Z git version 2.46.0
2024-09-18T06:24:14.3792531Z ##[endgroup]
2024-09-18T06:24:14.3807655Z Temporarily overriding HOME='/home/runner/work/_temp/55cfee19-4e4a-408c-b628-a746da38b883' before making global git config changes
2024-09-18T06:24:14.3809223Z Adding repository directory to the temporary git global config as a safe directory
2024-09-18T06:24:14.3820512Z [command]/usr/bin/git config --global --add safe.directory /home/runner/work/pydustmasker/pydustmasker
2024-09-18T06:24:14.3857688Z Deleting the contents of '/home/runner/work/pydustmasker/pydustmasker'
2024-09-18T06:24:14.3861123Z ##[group]Initializing the repository
2024-09-18T06:24:14.3866056Z [command]/usr/bin/git init /home/runner/work/pydustmasker/pydustmasker
2024-09-18T06:24:14.3928259Z hint: Using 'master' as the name for the initial branch. This default branch name
2024-09-18T06:24:14.3929877Z hint: is subject to change. To configure the initial branch name to use in all
2024-09-18T06:24:14.3931485Z hint: of your new repositories, which will suppress this warning, call:
2024-09-18T06:24:14.3932909Z hint:
2024-09-18T06:24:14.3933924Z hint: 	git config --global init.defaultBranch
2024-09-18T06:24:14.3935104Z hint:
2024-09-18T06:24:14.3935924Z hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
2024-09-18T06:24:14.3937121Z hint: 'development'. The just-created branch can be renamed via this command:
2024-09-18T06:24:14.3937842Z hint:
2024-09-18T06:24:14.3938256Z hint: 	git branch -m
2024-09-18T06:24:14.3939216Z Initialized empty Git repository in /home/runner/work/pydustmasker/pydustmasker/.git/
2024-09-18T06:24:14.3945604Z [command]/usr/bin/git remote add origin https://github.com/apcamargo/pydustmasker
2024-09-18T06:24:14.3977207Z ##[endgroup]
2024-09-18T06:24:14.3978073Z ##[group]Disabling automatic garbage collection
2024-09-18T06:24:14.3981420Z [command]/usr/bin/git config --local gc.auto 0
2024-09-18T06:24:14.4009039Z ##[endgroup]
2024-09-18T06:24:14.4009727Z ##[group]Setting up auth
2024-09-18T06:24:14.4015881Z [command]/usr/bin/git config --local --name-only --get-regexp core\.sshCommand
2024-09-18T06:24:14.4049959Z [command]/usr/bin/git submodule foreach --recursive sh -c "git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :"
2024-09-18T06:24:14.4355408Z [command]/usr/bin/git config --local --name-only --get-regexp http\.https\:\/\/github\.com\/\.extraheader
2024-09-18T06:24:14.4387779Z [command]/usr/bin/git submodule foreach --recursive sh -c "git config --local --name-only --get-regexp 'http\.https\:\/\/github\.com\/\.extraheader' && git config --local --unset-all 'http.https://github.com/.extraheader' || :"
2024-09-18T06:24:14.4616280Z [command]/usr/bin/git config --local http.https://github.com/.extraheader AUTHORIZATION: basic ***
2024-09-18T06:24:14.4657514Z ##[endgroup]
2024-09-18T06:24:14.4658787Z ##[group]Fetching the repository
2024-09-18T06:24:14.4668141Z [command]/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --no-recurse-submodules --depth=1 origin +512e209f5c51ed0b7ca0c73f732b488184b0034f:refs/remotes/origin/main
2024-09-18T06:24:14.9031166Z From https://github.com/apcamargo/pydustmasker
2024-09-18T06:24:14.9032936Z  * [new ref]         512e209f5c51ed0b7ca0c73f732b488184b0034f -> origin/main
2024-09-18T06:24:14.9054916Z ##[endgroup]
2024-09-18T06:24:14.9056294Z ##[group]Determining the checkout info
2024-09-18T06:24:14.9057659Z ##[endgroup]
2024-09-18T06:24:14.9062331Z [command]/usr/bin/git sparse-checkout disable
2024-09-18T06:24:14.9100739Z [command]/usr/bin/git config --local --unset-all extensions.worktreeConfig
2024-09-18T06:24:14.9128284Z ##[group]Checking out the ref
2024-09-18T06:24:14.9131628Z [command]/usr/bin/git checkout --progress --force -B main refs/remotes/origin/main
2024-09-18T06:24:14.9184911Z Switched to a new branch 'main'
2024-09-18T06:24:14.9188284Z branch 'main' set up to track 'origin/main'.
2024-09-18T06:24:14.9194373Z ##[endgroup]
2024-09-18T06:24:14.9231530Z [command]/usr/bin/git log -1 --format='%H'
2024-09-18T06:24:14.9255755Z '512e209f5c51ed0b7ca0c73f732b488184b0034f'
2024-09-18T06:24:14.9587230Z ##[group]Run actions/setup-python@v5
2024-09-18T06:24:14.9587918Z with:
2024-09-18T06:24:14.9588318Z   python-version: 3.9
2024-09-18T06:24:14.9588792Z   cache: pip
2024-09-18T06:24:14.9589219Z   check-latest: false
2024-09-18T06:24:14.9589856Z   token: ***
2024-09-18T06:24:14.9590300Z   update-environment: true
2024-09-18T06:24:14.9590822Z   allow-prereleases: false
2024-09-18T06:24:14.9591285Z env:
2024-09-18T06:24:14.9591667Z   CARGO_TERM_COLOR: always
2024-09-18T06:24:14.9592304Z   RUST_BACKTRACE: 1
2024-09-18T06:24:14.9592775Z   RUSTFLAGS: -D warnings
2024-09-18T06:24:14.9593253Z   PYTHON_VERSION: 3.9
2024-09-18T06:24:14.9593693Z ##[endgroup]
2024-09-18T06:24:15.1193416Z ##[group]Installed versions
2024-09-18T06:24:15.1255928Z Successfully set up CPython (3.9.20)
2024-09-18T06:24:15.1257643Z ##[endgroup]
2024-09-18T06:24:15.2093614Z [command]/opt/hostedtoolcache/Python/3.9.20/x64/bin/pip cache dir
2024-09-18T06:24:16.9952155Z /home/runner/.cache/pip
2024-09-18T06:24:17.3732465Z pip cache is not found
2024-09-18T06:24:17.3867904Z ##[group]Run python -m pip install -U pip
2024-09-18T06:24:17.3868506Z python -m pip install -U pip
2024-09-18T06:24:17.3869034Z python -m pip install -r requirements-dev.txt
2024-09-18T06:24:17.3869625Z python -m pip install -e .
2024-09-18T06:24:17.3870068Z maturin build --out dist
2024-09-18T06:24:17.3870633Z python -m pip install --no-index --find-links=dist/ prelude-parser
2024-09-18T06:24:17.3900530Z shell: /usr/bin/bash -e {0}
2024-09-18T06:24:17.3901033Z env:
2024-09-18T06:24:17.3901348Z   CARGO_TERM_COLOR: always
2024-09-18T06:24:17.3901730Z   RUST_BACKTRACE: 1
2024-09-18T06:24:17.3902435Z   RUSTFLAGS: -D warnings
2024-09-18T06:24:17.3902802Z   PYTHON_VERSION: 3.9
2024-09-18T06:24:17.3903253Z   pythonLocation: /opt/hostedtoolcache/Python/3.9.20/x64
2024-09-18T06:24:17.3903950Z   PKG_CONFIG_PATH: /opt/hostedtoolcache/Python/3.9.20/x64/lib/pkgconfig
2024-09-18T06:24:17.3904707Z   Python_ROOT_DIR: /opt/hostedtoolcache/Python/3.9.20/x64
2024-09-18T06:24:17.3905334Z   Python2_ROOT_DIR: /opt/hostedtoolcache/Python/3.9.20/x64
2024-09-18T06:24:17.3905908Z   Python3_ROOT_DIR: /opt/hostedtoolcache/Python/3.9.20/x64
2024-09-18T06:24:17.3906438Z   LD_LIBRARY_PATH: /opt/hostedtoolcache/Python/3.9.20/x64/lib
2024-09-18T06:24:17.3906976Z ##[endgroup]
2024-09-18T06:24:18.5790701Z Requirement already satisfied: pip in /opt/hostedtoolcache/Python/3.9.20/x64/lib/python3.9/site-packages (24.2)
2024-09-18T06:24:19.1811065Z Obtaining file:///home/runner/work/pydustmasker/pydustmasker (from -r requirements-dev.txt (line 7))
2024-09-18T06:24:19.1841263Z   Installing build dependencies: started
2024-09-18T06:24:20.0959658Z   Installing build dependencies: finished with status 'done'
2024-09-18T06:24:20.0970254Z   Checking if build backend supports build_editable: started
2024-09-18T06:24:20.1641341Z   Checking if build backend supports build_editable: finished with status 'done'
2024-09-18T06:24:20.1652563Z   Getting requirements to build editable: started
2024-09-18T06:24:20.2119528Z   Getting requirements to build editable: finished with status 'done'
2024-09-18T06:24:20.2132639Z   Preparing editable metadata (pyproject.toml): started
2024-09-18T06:24:22.8757188Z   Preparing editable metadata (pyproject.toml): finished with status 'done'
2024-09-18T06:24:23.0267426Z Collecting mypy==1.11.2 (from -r requirements-dev.txt (line 1))
2024-09-18T06:24:23.0362263Z   Downloading mypy-1.11.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_28_x86_64.whl.metadata (1.9 kB)
2024-09-18T06:24:23.0932767Z Collecting pre-commit==3.8.0 (from -r requirements-dev.txt (line 2))
2024-09-18T06:24:23.0971112Z   Downloading pre_commit-3.8.0-py2.py3-none-any.whl.metadata (1.3 kB)
2024-09-18T06:24:23.1683955Z Collecting pytest==8.3.3 (from -r requirements-dev.txt (line 3))
2024-09-18T06:24:23.1721066Z   Downloading pytest-8.3.3-py3-none-any.whl.metadata (7.5 kB)
2024-09-18T06:24:23.1981478Z Collecting pytest-cov==5.0.0 (from -r requirements-dev.txt (line 4))
2024-09-18T06:24:23.2067813Z   Downloading pytest_cov-5.0.0-py3-none-any.whl.metadata (27 kB)
2024-09-18T06:24:23.6443717Z Collecting ruff==0.6.5 (from -r requirements-dev.txt (line 5))
2024-09-18T06:24:23.6487755Z   Downloading ruff-0.6.5-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (25 kB)
2024-09-18T06:24:23.8177093Z Collecting maturin==1.7.1 (from -r requirements-dev.txt (line 6))
2024-09-18T06:24:23.8198335Z   Using cached maturin-1.7.1-py3-none-manylinux_2_12_x86_64.manylinux2010_x86_64.musllinux_1_1_x86_64.whl.metadata (18 kB)
2024-09-18T06:24:23.8434279Z Collecting typing-extensions>=4.6.0 (from mypy==1.11.2->-r requirements-dev.txt (line 1))
2024-09-18T06:24:23.8473206Z   Downloading typing_extensions-4.12.2-py3-none-any.whl.metadata (3.0 kB)
2024-09-18T06:24:23.8594382Z Collecting mypy-extensions>=1.0.0 (from mypy==1.11.2->-r requirements-dev.txt (line 1))
2024-09-18T06:24:23.8634156Z   Downloading mypy_extensions-1.0.0-py3-none-any.whl.metadata (1.1 kB)
2024-09-18T06:24:23.8800396Z Collecting tomli>=1.1.0 (from mypy==1.11.2->-r requirements-dev.txt (line 1))
2024-09-18T06:24:23.8818229Z   Using cached tomli-2.0.1-py3-none-any.whl.metadata (8.9 kB)
2024-09-18T06:24:23.8975977Z Collecting cfgv>=2.0.0 (from pre-commit==3.8.0->-r requirements-dev.txt (line 2))
2024-09-18T06:24:23.9029112Z   Downloading cfgv-3.4.0-py2.py3-none-any.whl.metadata (8.5 kB)
2024-09-18T06:24:23.9829165Z Collecting identify>=1.0.0 (from pre-commit==3.8.0->-r requirements-dev.txt (line 2))
2024-09-18T06:24:23.9871320Z   Downloading identify-2.6.1-py2.py3-none-any.whl.metadata (4.4 kB)
2024-09-18T06:24:24.0103535Z Collecting nodeenv>=0.11.1 (from pre-commit==3.8.0->-r requirements-dev.txt (line 2))
2024-09-18T06:24:24.0142150Z   Downloading nodeenv-1.9.1-py2.py3-none-any.whl.metadata (21 kB)
2024-09-18T06:24:24.0622591Z Collecting pyyaml>=5.1 (from pre-commit==3.8.0->-r requirements-dev.txt (line 2))
2024-09-18T06:24:24.0668233Z   Downloading PyYAML-6.0.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (2.1 kB)
2024-09-18T06:24:24.1675906Z Collecting virtualenv>=20.10.0 (from pre-commit==3.8.0->-r requirements-dev.txt (line 2))
2024-09-18T06:24:24.1716232Z   Downloading virtualenv-20.26.5-py3-none-any.whl.metadata (4.5 kB)
2024-09-18T06:24:24.1903000Z Collecting iniconfig (from pytest==8.3.3->-r requirements-dev.txt (line 3))
2024-09-18T06:24:24.1952839Z   Downloading iniconfig-2.0.0-py3-none-any.whl.metadata (2.6 kB)
2024-09-18T06:24:24.2221626Z Collecting packaging (from pytest==8.3.3->-r requirements-dev.txt (line 3))
2024-09-18T06:24:24.2263624Z   Downloading packaging-24.1-py3-none-any.whl.metadata (3.2 kB)
2024-09-18T06:24:24.2480947Z Collecting pluggy<2,>=1.5 (from pytest==8.3.3->-r requirements-dev.txt (line 3))
2024-09-18T06:24:24.2518853Z   Downloading pluggy-1.5.0-py3-none-any.whl.metadata (4.8 kB)
2024-09-18T06:24:24.2710359Z Collecting exceptiongroup>=1.0.0rc8 (from pytest==8.3.3->-r requirements-dev.txt (line 3))
2024-09-18T06:24:24.2746545Z   Downloading exceptiongroup-1.2.2-py3-none-any.whl.metadata (6.6 kB)
2024-09-18T06:24:24.6519578Z Collecting coverage>=5.2.1 (from coverage[toml]>=5.2.1->pytest-cov==5.0.0->-r requirements-dev.txt (line 4))
2024-09-18T06:24:24.6569313Z   Downloading coverage-7.6.1-cp39-cp39-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (8.3 kB)
2024-09-18T06:24:24.6847301Z Collecting distlib<1,>=0.3.7 (from virtualenv>=20.10.0->pre-commit==3.8.0->-r requirements-dev.txt (line 2))
2024-09-18T06:24:24.6881513Z   Downloading distlib-0.3.8-py2.py3-none-any.whl.metadata (5.1 kB)
2024-09-18T06:24:24.7187763Z Collecting filelock<4,>=3.12.2 (from virtualenv>=20.10.0->pre-commit==3.8.0->-r requirements-dev.txt (line 2))
2024-09-18T06:24:24.7229045Z   Downloading filelock-3.16.1-py3-none-any.whl.metadata (2.9 kB)
2024-09-18T06:24:24.7534185Z Collecting platformdirs<5,>=3.9.1 (from virtualenv>=20.10.0->pre-commit==3.8.0->-r requirements-dev.txt (line 2))
2024-09-18T06:24:24.7582411Z   Downloading platformdirs-4.3.6-py3-none-any.whl.metadata (11 kB)
2024-09-18T06:24:24.7763054Z Downloading mypy-1.11.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_28_x86_64.whl (12.5 MB)
2024-09-18T06:24:24.8653119Z    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 12.5/12.5 MB 143.4 MB/s eta 0:00:00
2024-09-18T06:24:24.8690107Z Downloading pre_commit-3.8.0-py2.py3-none-any.whl (204 kB)
2024-09-18T06:24:24.8793707Z Downloading pytest-8.3.3-py3-none-any.whl (342 kB)
2024-09-18T06:24:24.8868813Z Downloading pytest_cov-5.0.0-py3-none-any.whl (21 kB)
2024-09-18T06:24:24.8962871Z Downloading ruff-0.6.5-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (10.3 MB)
2024-09-18T06:24:24.9644029Z    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 10.3/10.3 MB 153.6 MB/s eta 0:00:00
2024-09-18T06:24:24.9664028Z Using cached maturin-1.7.1-py3-none-manylinux_2_12_x86_64.manylinux2010_x86_64.musllinux_1_1_x86_64.whl (8.7 MB)
2024-09-18T06:24:24.9771570Z Downloading cfgv-3.4.0-py2.py3-none-any.whl (7.2 kB)
2024-09-18T06:24:24.9927592Z Downloading coverage-7.6.1-cp39-cp39-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl (234 kB)
2024-09-18T06:24:25.0006437Z Downloading exceptiongroup-1.2.2-py3-none-any.whl (16 kB)
2024-09-18T06:24:25.0080099Z Downloading identify-2.6.1-py2.py3-none-any.whl (98 kB)
2024-09-18T06:24:25.0146675Z Downloading mypy_extensions-1.0.0-py3-none-any.whl (4.7 kB)
2024-09-18T06:24:25.0209743Z Downloading nodeenv-1.9.1-py2.py3-none-any.whl (22 kB)
2024-09-18T06:24:25.0272610Z Downloading pluggy-1.5.0-py3-none-any.whl (20 kB)
2024-09-18T06:24:25.0340858Z Downloading PyYAML-6.0.2-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (737 kB)
2024-09-18T06:24:25.0423108Z    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 737.4/737.4 kB 89.1 MB/s eta 0:00:00
2024-09-18T06:24:25.0441527Z Using cached tomli-2.0.1-py3-none-any.whl (12 kB)
2024-09-18T06:24:25.0478679Z Downloading typing_extensions-4.12.2-py3-none-any.whl (37 kB)
2024-09-18T06:24:25.0575323Z Downloading virtualenv-20.26.5-py3-none-any.whl (6.0 MB)
2024-09-18T06:24:25.1067812Z    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 6.0/6.0 MB 123.8 MB/s eta 0:00:00
2024-09-18T06:24:25.1107001Z Downloading iniconfig-2.0.0-py3-none-any.whl (5.9 kB)
2024-09-18T06:24:25.1174749Z Downloading packaging-24.1-py3-none-any.whl (53 kB)
2024-09-18T06:24:25.1245074Z Downloading distlib-0.3.8-py2.py3-none-any.whl (468 kB)
2024-09-18T06:24:25.1344410Z Downloading filelock-3.16.1-py3-none-any.whl (16 kB)
2024-09-18T06:24:25.1415430Z Downloading platformdirs-4.3.6-py3-none-any.whl (18 kB)
2024-09-18T06:24:25.1989220Z Building wheels for collected packages: pydustmasker
2024-09-18T06:24:25.1999002Z   Building editable for pydustmasker (pyproject.toml): started
2024-09-18T06:24:38.5767374Z   Building editable for pydustmasker (pyproject.toml): finished with status 'done'
2024-09-18T06:24:38.5775321Z   Created wheel for pydustmasker: filename=pydustmasker-0.1.0-cp39-cp39-linux_x86_64.whl size=2022 sha256=631b73d956599e638080f58643237666fc426978e48dbbce18ac20140813777a
2024-09-18T06:24:38.5777346Z   Stored in directory: /tmp/pip-ephem-wheel-cache-6m9qkbd4/wheels/1e/c1/f5/42b8fcea54a979e233b6ff9943c3b42d868e845f68440a4c24
2024-09-18T06:24:38.5796810Z Successfully built pydustmasker
2024-09-18T06:24:38.6283415Z Installing collected packages: pydustmasker, distlib, typing-extensions, tomli, ruff, pyyaml, pluggy, platformdirs, packaging, nodeenv, mypy-extensions, iniconfig, identify, filelock, exceptiongroup, coverage, cfgv, virtualenv, pytest, mypy, maturin, pytest-cov, pre-commit
2024-09-18T06:24:40.8533382Z Successfully installed cfgv-3.4.0 coverage-7.6.1 distlib-0.3.8 exceptiongroup-1.2.2 filelock-3.16.1 identify-2.6.1 iniconfig-2.0.0 maturin-1.7.1 mypy-1.11.2 mypy-extensions-1.0.0 nodeenv-1.9.1 packaging-24.1 platformdirs-4.3.6 pluggy-1.5.0 pre-commit-3.8.0 pydustmasker-0.1.0 pytest-8.3.3 pytest-cov-5.0.0 pyyaml-6.0.2 ruff-0.6.5 tomli-2.0.1 typing-extensions-4.12.2 virtualenv-20.26.5
2024-09-18T06:24:41.4626886Z Obtaining file:///home/runner/work/pydustmasker/pydustmasker
2024-09-18T06:24:41.4666849Z   Installing build dependencies: started
2024-09-18T06:24:42.3043297Z   Installing build dependencies: finished with status 'done'
2024-09-18T06:24:42.3054071Z   Checking if build backend supports build_editable: started
2024-09-18T06:24:42.3518437Z   Checking if build backend supports build_editable: finished with status 'done'
2024-09-18T06:24:42.3529366Z   Getting requirements to build editable: started
2024-09-18T06:24:42.3988830Z   Getting requirements to build editable: finished with status 'done'
2024-09-18T06:24:42.4000405Z   Preparing editable metadata (pyproject.toml): started
2024-09-18T06:24:42.6393543Z   Preparing editable metadata (pyproject.toml): finished with status 'done'
2024-09-18T06:24:42.6427158Z Building wheels for collected packages: pydustmasker
2024-09-18T06:24:42.6437401Z   Building editable for pydustmasker (pyproject.toml): started
2024-09-18T06:24:42.9118975Z   Building editable for pydustmasker (pyproject.toml): finished with status 'done'
2024-09-18T06:24:42.9127023Z   Created wheel for pydustmasker: filename=pydustmasker-0.1.0-cp39-cp39-linux_x86_64.whl size=2022 sha256=5367522e0566b9ca845f2d18fced5157a957e252ce6083f33e996feaf3900543
2024-09-18T06:24:42.9129133Z   Stored in directory: /tmp/pip-ephem-wheel-cache-7xh4ki9k/wheels/1e/c1/f5/42b8fcea54a979e233b6ff9943c3b42d868e845f68440a4c24
2024-09-18T06:24:42.9152730Z Successfully built pydustmasker
2024-09-18T06:24:42.9437893Z Installing collected packages: pydustmasker
2024-09-18T06:24:42.9439177Z   Attempting uninstall: pydustmasker
2024-09-18T06:24:42.9445295Z     Found existing installation: pydustmasker 0.1.0
2024-09-18T06:24:42.9465875Z     Uninstalling pydustmasker-0.1.0:
2024-09-18T06:24:42.9645103Z       Successfully uninstalled pydustmasker-0.1.0
2024-09-18T06:24:42.9766113Z Successfully installed pydustmasker-0.1.0
2024-09-18T06:24:43.0849894Z 📦 Including license file "/home/runner/work/pydustmasker/pydustmasker/LICENSE"
2024-09-18T06:24:43.0851590Z 🍹 Building a mixed python/rust project
2024-09-18T06:24:43.0852895Z 🔗 Found pyo3 bindings
2024-09-18T06:24:43.1605244Z 🐍 Found CPython 3.9 at /opt/hostedtoolcache/Python/3.9.20/x64/bin/python3
2024-09-18T06:24:43.1606840Z 📡 Using build options features from pyproject.toml
2024-09-18T06:24:43.2195589Z    Compiling target-lexicon v0.12.16
2024-09-18T06:24:43.2196508Z    Compiling once_cell v1.19.0
2024-09-18T06:24:43.2197416Z    Compiling proc-macro2 v1.0.86
2024-09-18T06:24:43.2204922Z    Compiling unicode-ident v1.0.13
2024-09-18T06:24:43.2815508Z    Compiling autocfg v1.3.0
2024-09-18T06:24:43.3831412Z    Compiling libc v0.2.158
2024-09-18T06:24:43.5994715Z    Compiling memoffset v0.9.1
2024-09-18T06:24:43.7211438Z    Compiling heck v0.5.0
2024-09-18T06:24:43.9184033Z    Compiling unindent v0.2.3
2024-09-18T06:24:43.9467364Z    Compiling pyo3-build-config v0.22.3
2024-09-18T06:24:44.0474136Z    Compiling quote v1.0.37
2024-09-18T06:24:44.2800100Z    Compiling syn v2.0.77
2024-09-18T06:24:44.2965382Z    Compiling indoc v2.0.5
2024-09-18T06:24:44.4419483Z    Compiling cfg-if v1.0.0
2024-09-18T06:24:45.1444106Z    Compiling pyo3-macros-backend v0.22.3
2024-09-18T06:24:45.1445326Z    Compiling pyo3-ffi v0.22.3
2024-09-18T06:24:45.1447340Z    Compiling pyo3 v0.22.3
2024-09-18T06:24:48.6507540Z    Compiling pyo3-macros v0.22.3
2024-09-18T06:24:51.0468378Z    Compiling pydustmasker v0.1.0 (/home/runner/work/pydustmasker/pydustmasker)
2024-09-18T06:24:51.7593000Z     Finished `dev` profile [unoptimized + debuginfo] target(s) in 8.56s
2024-09-18T06:24:52.5715440Z 📦 Built wheel for CPython 3.9 to dist/pydustmasker-0.1.0-cp39-cp39-manylinux_2_34_x86_64.whl
2024-09-18T06:24:52.9672194Z Looking in links: dist/
2024-09-18T06:24:52.9765624Z ERROR: Could not find a version that satisfies the requirement prelude-parser (from versions: none)
2024-09-18T06:24:52.9767752Z ERROR: No matching distribution found for prelude-parser
2024-09-18T06:24:53.0215088Z ##[error]Process completed with exit code 1.
2024-09-18T06:24:53.0322557Z Post job cleanup.
2024-09-18T06:24:53.1269403Z [command]/usr/bin/git version
2024-09-18T06:24:53.1307090Z git version 2.46.0
2024-09-18T06:24:53.1356280Z Temporarily overriding HOME='/home/runner/work/_temp/de5bfad5-43b6-4b75-b31c-091e03756b73' before making global git config changes
2024-09-18T06:24:53.1357401Z Adding repository directory to the temporary git global config as a safe directory
2024-09-18T06:24:53.1369900Z [command]/usr/bin/git config --global --add safe.directory /home/runner/work/pydustmasker/pydustmasker
2024-09-18T06:24:53.1406585Z [command]/usr/bin/git config --local --name-only --get-regexp core\.sshCommand
2024-09-18T06:24:53.1438680Z [command]/usr/bin/git submodule foreach --recursive sh -c "git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :"
2024-09-18T06:24:53.1686399Z [command]/usr/bin/git config --local --name-only --get-regexp http\.https\:\/\/github\.com\/\.extraheader
2024-09-18T06:24:53.1714400Z http.https://github.com/.extraheader
2024-09-18T06:24:53.1727449Z [command]/usr/bin/git config --local --unset-all http.https://github.com/.extraheader
2024-09-18T06:24:53.1762084Z [command]/usr/bin/git submodule foreach --recursive sh -c "git config --local --name-only --get-regexp 'http\.https\:\/\/github\.com\/\.extraheader' && git config --local --unset-all 'http.https://github.com/.extraheader' || :"
2024-09-18T06:24:53.2232588Z Cleaning up orphan processes
```

Thanks for reporting this, it is a bug. I had it in there while testing and forgot to remove it. Would you like to do a PR to remove it? It is in the github_actions.rs file.

Sure!

Done!
I also noticed that the CI is using some deprecated actions that will need to be replaced in the future, such as release-drafter@v5, <EMAIL_ADDRESS>and upload-artifact@v3. Since I haven't encountered any issues with them so far, I left them as they are.
Thank you for this tool, it is incredibly useful. It's unfortunate that it took me so long to discover it. Do you plan to write documentation? There are a few features I haven't used yet and would like to learn more about, such as the release drafter and the benefits of using the justfile over a traditional makefile.

Yes in testing your PR I also noticed there are some actions that need updating. You are welcome to update them if you like, otherwise I will do it.
Do you have thoughts around what needs additional documentation? I'm happy to accept PRs for that also, or to try to better document things you are unsure about.
The main benefits in my opinion to just are it woks on Windows also (make doesn't) and it was built with the purpose of running commands like this. Since make was really built for build C projects you sometimes need tricks like phony, just doesn't need this.

Got it, yes I can do that. I created a tracking issue here #464

Closed via #458


can not set fakeiOS7StatusBarColor

self.revealSideViewController.fakeiOS7StatusBarColor=[UIColor orangeColor];
[self.revealSideViewController resetOption:PPRevealSideOptionsiOS7StatusBarFading];

Error:
[PPRevealSideViewController setFakeiOS7StatusBarColor:]: unrecognized selector sent to instance

No issue with mine. Maybe upgrade your version


Protocol package Info()s (global) could just be global constants.

This would eliminate some function calls, and also eliminate code that is not called.

Well, maybe not.  Because putting it behind a function makes it safe given that we don't have constants. Still thinking about this.


How to reset/get a part of the query ?

Support Question
doctrine/orm Querybuilder provide the getDQLpart and resetDQLpart functions.
I found the debug function in the mongodb-odm ; in my use case, this could be use to get the sort part of my query, but I don't feel like this function is intended to be used in production.
Plus I found no way to reset a part of my query.
Am I missing something or some getQueryPart and resetDQLPart could be a nice new feature ?

These functions are still needed

@VincentLanglet mind making a PR? We're trying to wrap up 2.1 finally and for sure won't have time in foreseeable future to take care of this idea ourselves. Happy to chat on our Slack if you'd need anything tho.

@VincentLanglet mind making a PR? We're trying to wrap up 2.1 finally and for sure won't have time in foreseeable future to take care of this idea ourselves. Happy to chat on our Slack if you'd need anything tho.

I may try when I'll find time. But I've just posted a message to avoid this issue to be closed by the bot.


Set git user and email

About this change - What it does
Sets the git user and email for the github pages publish step.
Why this way
Since there is no checkout for the publish step the git user/email is not being set, this change rectifies that problem.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 76.676%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
263

Relevant Lines:
343

💛  - Coveralls


fix discourse location

https://github.com/ga4gh/dockstore/issues/1305

It's the infamous postgres timeout.  I have a fix attempt for it but not entirely confident it actually works.


IPR Dash live multi-period stops after first manifest

Have you read the Tutorials?
yes
Have you read the FAQ and checked for duplicate open issues?
yes
What version of Shaka Player are you using?
4.5.0
Please ask your question
Hello, we wish to test shaka player to reproduce dash live.
Our test case is – please correct us if we are wrong – what in shaka is defined as an IPR stream. That is, we have static media content (therefore segments are always available) that we wish to present in a sliding window fashion in order to display the content including ads.
To achieve this, we create a multi-period dash live manifest (see links below).
The proof of concept we are doing tries to get shaka to play the following timeline:

We publish manifest_1, which contains:
Request client to update every 30 sec
30 sec of media_1, starting from media_1 t=0
30 sec of media_2 (to simulate an ad), starting from media_2 t=0
60 sec of media_1, starting from media_1 t=30, to restart media playback from where the user left off.
We start shaka player
At some point during the first minute of playback, we republish the manifest to become manifest_2, which contains:
Request client to update every 30 sec
30 sec of media_2, starting from media_2 t=0
30 sec of media_1, starting from media_1 t=0
30 sec of media_2, starting from media_2 t=30

Our expectation was that the player, upon reloading the manifest would realize that new periods had been added and extend its timeline accordingly.
However, what happens is that the player stops playback after the first manifest media ends. The reason being that shaka considers the last period of the first manifest to be the final one of the timeline, and then stops updating.
We found several workarounds, but we wish to understand what is the correct way to design the manifests, not use the “hack the code until it works” approach, and to understand why shaka fails to play the second manifest.

Workaround_1 was to modify dash_parser.js forcing isLastPeriod to be always false.
However, we do not like this solution because checking the code we see that the purpose of the isLastPeriod is to flag which is the last period in the manifest, and it was doing this correctly. What we want to understand is why a manifest update does not overwrite the timeline to update the last period to become the last one of the new manifest.

Workaround_2 was to modify the manifests, not the shaka code, by setting the playlists to static and removing the TimeBufferShiftDepth variable.
Again, we do not like the solution because conceptually our manifest is indeed live, as new periods keep appearing in the timeline.

Workaround_3 was to set extremely high values for TimeShiftBufferDepth and MediaPresentationDuration, and make those values the same.
We do not like this solution because TimeShiftBufferDepth should be 0 if we do not want the player to be able to navigate to a previous point in the playback.

Any of the above workarounds makes shaka play the timeline as expected.
Also, Manifest_1 and Manifest_2 work if played individually.
You can find the playable manifests in:
https://s3-eu-west-1.amazonaws.com/dev-test-shared/dashlive/manifest_1.mpd
https://s3-eu-west-1.amazonaws.com/dev-test-shared/dashlive/manifest_2.mpd
We would be very grateful if someone could tell us the proper way to achieve correct timeline update.
As extra information, shaka complains about our manifests with this assertion fail:
“Detected as IPR stream, but does not match our model of IPR! “

Is this scenario correct?

We publish manifest_1, which contains:
Request client to update every 30 sec
30 sec of media_1, starting from media_1 t=0
30 sec of media_2 (to simulate an ad), starting from media_2 t=0
60 sec of media_1, starting from media_1 t=30, to restart media playback from where the user left off.
We start shaka player
At some point during the first minute of playback, we republish the manifest to become manifest_2, which contains:
Request client to update every 30 sec
30 sec of media_2, starting from media_2 t=0
30 sec of media_1, starting from media_1 t=0
30 sec of media_2, starting from media_2 t=30

Manifest updates should only ever remove content from the beginning and/or add content to the end.  Here, it drops the first 30s of media_1, which is fine, but it replaces 60 sec of media_1, starting from media_1 t=30 with  30 sec of media_1, starting from media_1 t=0;  30 sec of media_2, starting from media_2 t=30.
After telling the player about some segments, you can't replace those with different segments in an update.
This would work (my edits in bold):

We publish manifest_1, which contains:
Request client to update every 30 sec
30 sec of media_1, starting from media_1 t=0
30 sec of media_2 (to simulate an ad), starting from media_2 t=0
~60~ 30 sec of media_1, starting from media_1 t=30, to restart media playback from where the user left off.
We start shaka player
At some point during the first minute of playback, we republish the manifest to become manifest_2, which contains:
Request client to update every 30 sec
30 sec of media_2, starting from media_2 t=0
30 sec of media_1, starting from media_1 t=~0~ 30
30 sec of media_2, starting from media_2 t=30


Add full covariance matrix support

Will need to adapt sklearn full covariance routines to CUDAMat.

Hey!
Is this repo going to be supported?

Is this repo going to be supported?

Unfortunately, I won't be working on it, but I'd be glad to review contributions.

@ebattenberg ok, thank you. And is are these scripts well tested?) If have some time, will work on that I guess)

@ebattenberg BTW, when I try to estimate gmm from 100.000 samples with 26 dimensions, I get CUDABlas error with no explanation

I haven't run the code in about 4 years, so I can't guarantee that it will
continue to work with current versions of CUDA.  Sorry.
On Tue, Oct 10, 2017 at 11:24 PM Artemiy Firsov<EMAIL_ADDRESS>wrote:

@ebattenberg https://github.com/ebattenberg BTW, when I try to estimate
gmm from 100.000 samples with 26 dimensions, I get CUDABlas error with no
explanation
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ebattenberg/ggmm/issues/2#issuecomment-335695535, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABUEeuDC9xuYWNhzc4yljCVcGuDwkcCaks5srF8agaJpZM4CRSEq
.


Improve platform-specific READMEs to add useful links

This also adds READMEs for all platforms.
This can be remade for 3.x once we agree on this PR.

Thanks!


PC crash after installing Ollama

What is the issue?
After following the installation instructions in Ollama for Windows, running ollama pull command will crash my PC. The same goes for WSL, crash after running the ollama command.
OS
Windows, WSL2
GPU
Nvidia
CPU
Intel
Ollama version
No response

@tyseng92 make sure you're running the latest nvidia drivers.  When it crashes, do you get a BSOD, and if so, which driver was active?

If you're still seeing problems after upgrading to the latest nvidia driver, please let us know.


Docgen does not pick up types from d.ts declaration files

Bug Report
Describe the bug
The docgen props parser properly picks up types found in TS source files, but it does not pick up types that declared in d.ts files next to .js files.
I have some custom build settings that would be difficult to replicate in webpack and want to build my packages first, and then have Docz find the related MDX files that import the build .js and d.ts packages.
Expected behavior
I would expect the props parser to find the .d.ts files and find the related prop types to be included in the docgen output.
Environment

OS: OSX 10.13.6
Node 8/npm 5

I also thought about it.
Originally planned to separate the library and documentation in different repositories.
But there is the big problem in that when building the library, the react components lack metadata and cannot be unambiguously compared with the source files (including d.ts).
But from a practical point of view, there is such an opportunity.  Do not strictly match the names of files and properties of components (eg. displayName), in most cases this will be enough. For this you need:

For each documented component, specify displayName property, which is equal to its file name.
Modify the doczrc.js like this:

export default {
  typescript: true,
  docgenConfig: {
	  propFilter: () => true,
	  searchPath: 'node_modules/your-component-library',
	  },
  filterComponents: (files) =>
    files.filter(filepath => /\/[A-Z]\w*(.d)?\.(js|jsx|ts|tsx)$/.test(filepath))
}

Also minor improvements of the Docz are required. PR I prepared.
@pedronauck, what do you think?

Interesting. Yea it would be nice if there was better support.
This was very important for me so i ended up with the following workaround:
//doczrc.js

export default {
  filterComponents: () => Object
    .entries(require('./package.json').dependencies)
    .map(([dep]) => {
        const { types } = require(`${dep}/package.json`);
        if (types) {
          return path.relative(__dirname,  require.resolve(`${dep}/${types}`));
        }
    })
    .filter((typesPath) => !!typesPath)
}

And then I re-wrote the paths for the db props inside a "custom" theme that just redirects into the default theme
import Theme from 'docz-theme-default';
import { createElement, FC, useMemo } from 'react';

export const ThemeWrapper: FC<any> = ({
  db,
  ...props
}) => {
  // We have to re-write the props so we can support .d.ts files instead of JS files
  if (db && Array.isArray(db.props)) {
    db.props.forEach((prop: any) => {
      const ext = '.d.ts';
      if (prop.key && prop.key.endsWith(ext)) {
        prop.key = prop.key.slice(0, ext.length * -1) + '.js';
      }
    });
  }
  return <Theme {...props} db={db} />;
};

The main issue here is that the d.ts has to be right next to the .js file, which was true for how i configured all of my projects. But that might not be true for all projects.

Another potential solution that would better for Docz likely is if "allowJS" was forced in the ts files, and then .js files were also pushed through the ts docgen parser which should also allow the TS parser to read the .d.ts files and then match up the metadata by export name. I could not get that working however without changes to docz which I was not wanting to do.

How to use this with d.ts file ? Could you provide a simple demo ? I try it such as above , but not work.

@NexxLuo, like in this comment?

My mdx files is in examples , d.ts is in folder types .
How to let the Props  render by the d.ts file  ?

The doczrc.js like this, is that right?
 export default {
  typescript: true,
  docgenConfig: {
	  propFilter: (prop) => prop.parent.fileName.includes('types'),
          resolver: (exp, source) => {
		  var name = path.basename(source.fileName, path.extname(source.fileName))
		  return path.basename(name, path.extname(name))
		  },
	  searchPath: 'types',
	  },
  filterComponents: (files) =>
    files.filter(filepath => /\/[A-Z]\w*.d.ts$/.test(filepath))
}```

@NexxLuo, possibly, index.d.ts file not matched by regexp in filterComponents /\/[A-Z]\w*.d.ts$/.


Namespaces of XML elements are hardcoded

Right now, elements other than the default namespace are identified for example as follows:
@XmlElement(name = "Substation", namespace = "http://iec.ch/TC57/2013/CIM-schema-cim16#")
Namespaces are very changeable, so this needs to be fixed.
Or at least, now being hardcoded.

Issue closed because input files are now being processed with RDF4J