Test tape device with a VAXstation 3100 running OpenVMS 7.2

This is a follow-up ticket for https://github.com/uweseimet/scsi2pi/issues/100, dealing with issues found when testing the tape device. The OS reports "tape is not valid ANSI format" when trying to list files after a foreign mount operation.

These are the logs and scripts for this ticket.

Foreign mount script:
issue_111_script.txt

Logfile when sending this script to s2p:
mount_s2p.txt

Logfile when sending this script to the Sony tape drive:
mount.txt

@pacjunk Please add whether may be missing.

Correction: The mount/foreign works correctly. The error occurs when using the backup/list command to list the contents of the first saveset.  If the tape is mounted normally (files11), then the first file can be copied from tape to disk and read successfully - which shows that the tape is formatted correctly, and the files are valid. Simh can read the same .tap file (although not emulating SCSI), and a physical SCSI tape drive also works correctly.

I sse, I confused the commands. s2p can also read the file, but it has to report a SCSI error because of the block mismatch. s2p does not have an issue with the file, but with the combination of block sizes in the file and the SCSI command to read these blocks.
Can you please attach the s2p log that results in your OS complaining?

This is the trace log for the mount/foreign command - which completes successfully.
mount.txt
This is the log for the backup/list (what I was calling foreignlist) - which fails and produces the error "tape is not valid ANSI format". This is because it attempts to read the label block and s2p signals an error because of block size mismatch.
list.txt

Just to ensure that the test scenario for this ticket is correct: First mount.txt has to be applied, then list.txt. With your drive this sequence of commands works fine, with s2p it results in an error.

Correct

Good, but these were only the logs. Can you please add the matching scripts?

A question regarding the ANSI format: The initial blocks in the .tap file we use for testing is 80 bytes. Is this ANSI format? I am asking because your OS reports an ANSI-related error when trying to read 90 byte blocks from this file. If the 80 bytes are ANSI format, trying to read 90 bytes can never succeed, also not with a real tape drive.

Yes, that is ANSI.
I found some information on VMS 8.4 (quite a bit later, and not using this architecture, but tape formats havent changed for years). Link is https://community.hpe.com/t5/operating-system-openvms/openvms-8-4-backup-log-disk-test-mga0-test-bck-save-not-working/td-p/4830493. The person is getting the same error messages as me. One of the replies states the following:
backup sets up a 90-byte buffer for reading the VOL1 header and EXPLICITLY checks the IO status block for 80 bytes being returned from the QIO and returns BACKUP$_NOTANSI, if that check fails.
It contains the magic number "90". I know this is not a proper solution, but what would happen if when the request is for 90 bytes, s2p just returns the data in the block (80)?

Where would take s2p the additional  data from? Note that your tape drive also does not return more data than available, but signals the mismatch in the response, in the same way s2p does. RQUEST SENSE then provides the details, with custom bytes at the end of the added by your drive.

What additional data? The above statement says that the device just returns the 80 bytes (and I assume there is a length field somewhere indicating the length of the response?)
The tape drive must at some stage return the required data though, otherwise it wouldn't work.

The drive in the sense data provides the difference of requested vs. available data, and that's it. It will never return more data than the block size, because more data for the requested block just do not exist. We have already verified that your drive and s2p handle this case identically, and according to the specs.
IMO the fact that your OS tries to read 90 bytes at all is something that should not happen. I bet with your drive it does not happen, because we have already seen that the drive would report the same error as s2p, except for the custom bytes.
If the custom bytes have no relevance, it means that something must have happened before, which caused your OS to do what is does in the s2p case.
I need to check all commands in the logs again, but I would need current logs for the two relevant operations.

With the mode page stuff set, the only difference is the mount now reports that the tape is write locked.
mount.txt
list.txt
I will run the script soon...

OK, thanks a lot.
I may just have found something relevant while re-checking all logs. I still don't know why my streamer does not work with Linux and the Atari. When using s2pexec with it I can successfully run the init script and can read the data it writes. When doing this I noticed that even that in the mount log there is a difference in the error data returned when the first filemark is hit. The OS reads the first 3 blocks, then there is another read command. This one has to fail because after the third block there is a filemark. This raises an error (with your drive, with my drive, and with s2p), but s2p does not return the actual block size in the error message, whereas my drive does. I am in the process of updating s2p accordingly.

I ran the script twice. The first time it produced a message "Error: UNIT ATTENTION (Sense Key $06), NOT READY TO READY TRANSITION (MEDIUM MAY HAVE CHANGED) (ASC $28), ASCQ $00". The second time, no such message.
output.txt
output2.txt

Wrt your latest comment: I don't know what you mean with "mode page stuff set".

Running the script on your drive has revealed what the MODE SELECT does. With the MODE SENSE before the MODE SELECT your drive says that it has a default block size for fixed size read commands of 512 bytes. The MODE SELECT changes this. After the MODE SELECT your drive return 0 as default block size. The spec says:
"The block length specifies the length in bytes of each logical block described by the block descriptor.  For sequential-access devices, a block length of zero indicates that the logical block size written to the medium is specified by the transfer length field in the command descriptor block (see 10.2.4 and 10.2.14)"
This is not yet what s2p does. I will change this.

The block size change works now. Can you please check if this already improves something after updating and re-compiling issue_100? Important: Remove the mode page line from /s2p.conf.

The mount crashes s2p with floating point exception
mount.txt

I just committed a fix so that when htting a filemark the requested length is returned. The exception is most likely also fixed in the very latest issue_111 sources.

Same floating point exception
mount.txt

I see, please provide the script, so that I can reproduce the issue with my setup.

I may have found what's wrong without a script (but would still like to have it). Please update once more and re-test.

That fixed the floating point exception. Logs for mount:
mount.txt
mount_script.txt
Backup/list still fails. Logs:
list.txt
list script.txt

Tthe sense data when hitting the filemark in the mount test are now correct.
Please configure a custom mode page 0 again, this time with a block size 0, by updating /etc/s2p.conf:
mode_page.0.SCSI2Pi:SCSI TAPE=0b:00:90:08:13:00:00:00:00:00:00:00

Then please run the list test and provide script and log.

list.txt
list script.txt
I'm packing up for the night. I will check in tomorrow. Cheers,

Thank you, and good night. At least two more issues have been fixed by comparing with real drive data. I will later evaluate the new logs.

I updated s2pexec to log all we need on debug level, without all the noisy bus phase etc. messages, which are now only logged on trace level. From now on, please add "-L debug" at the beginning of each script you execute with s2pexec. This will make the logs much shorter and better readable.

Where is the init script, or do you just want me to label the tape with the OS?

Yes, that's what I meant, i.e. running the process that creates a file of this structure:
Offset 0 ($0): Class 0, good data record, record length 80 ($50)
Offset 88 ($58): Class 0, good data record, record length 80 ($50)
Offset 176 ($b0): Class 0, good data record, record length 80 ($50)
Offset 264 ($108): Class 0, tape mark
Offset 268 ($10c): Class 0, tape mark
Offset 272 ($110): Class 0, good data record, record length 80 ($50)
Offset 360 ($168): Class 0, good data record, record length 80 ($50)
Offset 448 ($1c0): Class 0, tape mark
Offset 452 ($1c4): Class 0, tape mark
Offset 456 ($1c8): Class 7, private marker (SCSI2Pi end-of-data object)

I use this script for this because I cannot have any OS do this:
init_script.txt
We have to ensure that regardless of with or without OS, with or without real tape drive, our test scenario is always equivalent with running init, mount and list in this order.

OK here is what I did...
I ran your init script, then the mount script, then the list script:
init_out1.txt
mount_out1.txt
list_out1.txt
Then I attempted to mount the tape in the OS that had been initialised with your script. This worked for both Files11 and foreign mounts.
I then re-initialised the tape with the OS (same label) and reran the mount and list scripts:
mount_out2.txt
list_out2.txt

This means all in all, the init script, which is the only script that writes and data, does excactly do the same as labeling does. Correct me if I am wrong, please. The other two scripts only read, but do not write.

I just tested the mount command. To be sure I need to copy some files to and from the tape. I have switched the gear off for a little while as there is a thunderstorm rolling through. I'll test after that.

Sure, no problem. The plan is to return exactly the same data as your drive. Even the synchronous transfer bit, which cannot be supported. When your OS sees exactly the same data, something must change in what the OS does when s2p is connected, because it cannot tell the difference between emulation and real hardware.

Somehow my tape got corrupted. I got errors when copying files to it.  I did an erase on the tape, then initialised it again and things work properly. I then re-ran your init script and copied files and this time it all worked.
I don't know what happened before and why it got corrupted. but seems OK now.

This is what happens when the OS boots. I assume it is just scanning the SCSI busses looking for devices.
boot.txt
boot_script.txt
Anyway, I'm off to bed...

Thank you, my job is now to once again have a close look at everything.

Result of comparing the two mount_out1 and mount_out2. There are differences, but in practice they do not matter:

When running mount_out2, the tape had not been rewound, according to what READ POSITION report. But your OS sends a REWIND anyway, and the subsequent commands were executed at the correct position, i.e. the beginning of the tape.
The "HDR1" labels have different numbers in them: "4341024329" and "4041024341". I guess these are timestimps and they do not matter. Maybe you know more about the meaning of these numbers?
Assuming that these numbers do not matter the logs show that the mount operation does the same with the tapes labeled by our OS as with the tapes labeled by the init script.

Build f5d15c2
This is a combined mount and list log (since you said temporary values may change if I stop s2p):
mount&list.txt
mount&list script.txt
I think it has got to the stage where we need to run scsimon or something similar to see what the real tape drive does about the 90 byte request. I have scsimon dumps, but don't know how to interpret them.

Yes, but the operation on the real drive is successful. So either it must ask for 90 bytes and get 80, or it must ask for 90, get rejected then ask for 80. Whatever it does, the operation succeeds. Thats why I think it would be useful to monitor the traffic to see how it works.

I'm afraid I have to disagree: The read operation of 90 bytes is not successful with the real drive. s2pexec clearly shows that. And the specification says that a drive must not return data in this case.
This is why I doubt that the sequence of commands when your drive is connected results in this read operation at all. Something else must be different before.

By the way, using a different drive would be a good idea at this point. I expect the same result, i.e. that it will just work, but maybe we learn something knew.

So if you believe that the OS never asks for a 90 byte block with the real tape drive, then it would be useful to monitor it and prove that.

I would not know how to prove that. But I believe that this read never happens because we have proven by running such a command against your drive, that your drive will raise an error. And we know that the specification says that your drive has to do just that. This is consistent. This is why I think it is reasonable to believe that this read never happens.

I am just wondering: Would using the simh emulator help? I don't have the required knowledge to use it, but I guess it is running a similar or the same OS in the emulation? The emulation must have its own drivers to access simh image files, but the OS would still run the same commands it runs on your real hardware, wouldn't it? And their might be means to monitor what the OS when running on simh does.

What I am also wondering. Let's forget the technical details in the logs for a moment: Why would your OS think that this tape is a different kind of tape, i.e. one with 90 byte blocks? You have mentioned that this kind of blocks exists in a different context, haven't you? Why would the OS think that it is in such a context?

The tape drives in simh are not SCSI, so it would be hard to compare.
I can't see why the OS would look for actual 90 byte blocks, because it would then not be ANSI compliant.

OK, so simh would not help. I had a brief look at the simh project pages yesterday. But since I have never used VMS I don't think that I would be the right person to try out simh.
Regarding the OS: From the logs we know that there are situations in which the OS does look for a 90 byte block, because it explicitly tries to read a block of this size. This means it knows something about non ANSI compliant blocks. When being connected to s2p it thinks that using this block size is a good idea. This is why I wonder when the OS might think that.

I think we are at a point where it is really hard for the two of us to proceed. There were one or two other users who commented in the previous tickets I think. It would be good to have more testers, with other platforms. This might reveal something new, because using more/other drivers will provide additional insight.

simh does more than just VMS, but they are mostly minicomputer type systems with heaving leaning  towards DEC gear. Written by a DEC guy, so I suppose this makes sense. I think the tape drive stuff emulates a TQK50 controller. Certainly the device name (MU) supports that. If it was SCSI it would be MK.  There is a fork of simh that supports later workstations (including mine), but it only supports SCSI disks. Tape is still non-SCSI.
What would happen (as a test) if the s2p code didn't generate an error and just returned the 80 bytes? Would be interesting to see.

Your OS requests 90 bytes in the DATA OUT phase. Just returning 80 will cause issues, e.g. a blocked bus. We simply have to accept that also the real drives do not return 80 bytes in this case, and that this is compliant with the specification. The drives and s2p do the right thing in this context.

Looks like we're never going to find out then!
If this is a dead end, I suggest we move onto writing files to the tape (reading seems to work)

@bog-dan-ro You mentioned that you wanted to implement tape support for PiSCSI. This appears to be stalling, but anyway: I would appreciate your help with testing the SCSI2Pi tape support. The current state is already far beyond what your suggested code for PiSCSI provides. It also supports non-fixed block sizes and simh-compatible image files.
@Pacjunk and I have spent a lot of time with testing s2p against OpenVMS, but we appear to be in a dead end. This is why an additional tester, with an additional platform, would be very helpful. Maybe you would like to help us? In this case, please note that I would need rather prompt feedback on a regular basis.

@Pacjunk I agree, let's continue with writing. I would not be surprised if we learn something when dealing with other features, i.e. writing, that helps us with the current problem.

@sidick @ppuskari You also expressed interest in tape support. If you are still interested, this is the right time to help with testing.

@Pacjunk I assume that you are going to start with a new test case. If there is something that does not work, please post the required data - you have a lot of practice with this now ;-) - and I might create a new, specific ticket for this case.

OK. Here are some logs. I initialised a tape in the normal way (don't think we need logs for that now).  The .tap file is 64KB in size.
I then mounted the tape (not foreign like we were doing). This worked.
mount.txt
mount script.txt
Then I tried to copy a small file (probably on 40 bytes of real data) to the tape...
copy.txt
copy script.txt
The main error message I got, said that "magnetic tape position lost". I assume it didn't find the right place to append the ANSI header and/or the data for the file.

@Pacjunk Thank you. I will investigate this. I created https://github.com/uweseimet/scsi2pi/issues/112 for dealing with writing data to a tape with your platform. Please from now on let's use the new ticket for anything related to writing data, so that the current ticket remains focused on the 90 bytes etc. issue when reading.

@Pacjunk Regarding the list operation, let me make some claims/assumptions. Please comment on what you think is wrong and why. This is not so much about s2p, but about the operations executed by the OS.

Your OS knows about 90 byte blocks, even though they may not be ANSI. Otherwise it would not try at all to read exactly 90 bytes. The 90 is not a random number.
Tapes that do not have 80 byte blocks at the beginning cannot be mounted.
Mounting a tape is a precondition for the list operation.
Because the tape could be mounted, the OS knows that the first block has 80 bytes.
After mounting a tape the tape is positioned at the beginning, because the mount operation executes a rewind at the end.
Despite this knowledge the OS tries to read 90 bytes from the beginning with the list operation

Yes getting back into this and will get stuff deployed asap. Job change has really eaten into my play time. lol.
Appreciate all the work that you have done.
Sent from my iPhone
On Dec 7, 2024, at 4:20 AM, Uwe Seimet @.***> wrote:

@sidickhttps://github.com/sidick @ppuskarihttps://github.com/ppuskari You also expressed interest in tape support. If you are still interested, this is the right time to help with testing.
—
Reply to this email directly, view it on GitHubhttps://github.com/uweseimet/scsi2pi/issues/111#issuecomment-2525061582, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAIMVUHVC4HJVUZV3NXTK6D2ELDVTAVCNFSM6AAAAABS73SEU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRVGA3DCNJYGI.
You are receiving this because you were mentioned.Message ID: @.***>

Thinking about this 90 byte block, I think this is a quick test to see if the tape is in ANSI format. Here is my theory:
The backup command will require that the tape be in ANSI format, so it requests a 90 byte read.
When this generates an error (most likely):
If the reply says that the block is only 80 bytes (short by 10), then the utility goes on to process the ANSI headers and file system
If the reply says the block is any other length (or succeeds), then the tape is not ANSI and backup cannot continue.
I think this is what must be happening. Mounting a tape foreign doesn't care about the format. If you mount a zero filled file, it reports no label, but it still mounts it. This is for transfering data to/from a "foreign" format. Backup requires a foreign mount, but does care about ANSI format, so must test it as above.
I think the issue must be about how s2p handles the response to the invalid block request.
I will run your tests soon, but I wanted to put forward this theory!

I ran your check position script. The first time it generated errors, so I ran it again.
check.txt
I then mounted the real tape foreign, switched off the tape drive, started s2p, then did the backup/list. Same error - which is expected as it is the backup command that generates the 90 byte read. As I said in the last comment, the foreign mount doesn't really care what format the tape is in. If it is ANSI, then it will display the label. If not, it just says no label and continues anyway.

I tried it the other way around (mount the s2p tape, then read the real tape), but this failed as it said the drive contains the wrong tape. There must be a serial number on it, because despite having the same label, it knows it has been changed. In theory your test should work as it is the backup/list command that causes the issue.

I think the issue must be about how s2p handles the response to the invalid block request.

I'm afraid this collides with what the logs say: They all say that s2p does the same as your drive does when there is a block that has 80 bytes but 90 bytes are requested. It is also the same as my drive does, and matches what the specification says must happen. When receiving this response your OS stops sending commands.
Until now the logs have exactly reflected what has happened and where s2p and your drive differs, so that I could address the problem. Maybe I misunderstand you: Do you mean that in this particular case the logs are misleading/wrong?

The check script shows that the drive is at position 0. This is expected, but we needed to verify this.

I think you meant 08 there, rather than 03.
Anyway, with a blank tape I got:
blank.txt
With the tape with the backups on it (which is the one we should be working with) I got:
full.txt
I can't see a serial number there, and I initialised a tape twice and the results are identical. Some how the OS knew that I had switched the tapes.

Yes, 08, you are right.
Regarding the OS, it can only know that something was switched in 2 cases:

The new device reports UNIT ATTENTION, POWER ON on first read access. Your drive does this, but s2p does (intentionally) not.
The OS looks at the data transferred. If the data s2p uses are identical with the data on the tape, there is no difference from the OS perspective.

Regarding this test, there are two tapes with different contents, blank and full. I don't know whether there are any serial numbers, but the data differ. But if you start your test with such a real tape, and then switch to s2p, which uses a .tap file with exactly the same content as the tape, the OS cannot know. Reasoning see above.
I will create a .tap file with the same content as the full.txt tape, and then let's see what happens.

One more question: The data of full.txt are completely different from the data we used previously. We have at least 4 data blocks, but no tape marks at the beginning. Previously, for the list test, we were using these data:
Offset 0 ($0): Class 0, good data record, record length 80 ($50)
Offset 88 ($58): Class 0, good data record, record length 80 ($50)
Offset 176 ($b0): Class 0, good data record, record length 80 ($50)
Offset 264 ($108): Class 0, tape mark
Offset 268 ($10c): Class 0, tape mark
Offset 272 ($110): Class 0, good data record, record length 80 ($50)
Offset 360 ($168): Class 0, good data record, record length 80 ($50)
Offset 448 ($1c0): Class 0, tape mark
Offset 452 ($1c4): Class 0, tape mark
Offset 456 ($1c8): Class 7, private marker (SCSI2Pi end-of-data object)

I guess I am missing something here. Just to ensure that we are talking about the same: The new test is supposed to look like this:

Boot your OS with the Sony drive connected, and with a tape that is suitable for running the list test.
Keep the Sony drive connected until the list command.
Before the list command disconnected the drive and launch s2p with an image file (the one I am going to create) that has the same contents as the tape present when booting.
Now run the list command with the OS.
The OS will not have noticed that there is s2p now instead your drive, reasoning see above.
With this setup we will learn if whatever goes wrong with s2p it is triggered by something that happened before the list command, or if it is really the list command itself where something goes wrong.

Thank you for your help today.
Regarding the switch: The OS detects that the drive has changed because it reports UNIT ATTENTION. But again, I claim that we are smarter than the OS. We will snatch this information aways from it.
In order to do that, after connecting the real tape and before having the OS execute the list command, launch s2pexec. Then manually run a TEST UNIT READY:
-i 3 -c 00:00:00:00:00:00

The drive will report UNIT ATTENTION, but it will only do this once. Now run the list operation with your OS.

That would be fantastic. Then we would know the tapes were identical.
I have been looking at the scsimon trace (I captured doing a list to the real tape drive) in GTKWAVE and found the read command for 90 bytes. Data seems to flow according to the trace...
The command:

I assume the zero after the msg line goes high is a success status? Dont know what the 04 is.

Start of the data flowing in... (at the 'V'):

Obvious reading of the label

There are a couple of other examples of the 5A read and they return the HDR1 and HDR2 blocks. Same codes inbetween the read command and data flowing.

At least for the current tests, where I faked the tape contents, we can be sure that everything is identical. s2psimh and s2pexec show that.

Any comment on the scsimon trace above?

I don't know what it means, but I have not left out any of the trace. It goes straight from sending the command to retrieving the data. I don't know what the 00,04,00,08,48,80 values are in between the command and the data. You would know better than me!

I'm afraid I do not know. There cannot be any data base values that are not also visible somewhere in the s2p logs.. 00, 04 are rather ubiquitous. 80 may be 80 bytes, but could also be something else.
Please run the test with the switched drive. It would at least provide a bit more information. I don't think that the positioning fixes done for #112 are also relevant for this ticket, but checking whether something has improved with the latest code also for #111 may be worth trying.

Just for fun I tried scsimon with Linux and my tape drive. The sg_inq Linux tool sends two INQUIRY commands and, depending on the outcome, a REQUEST SENSE. A very simple scenario.
scsimon misses about 2 bytes out of 3. Therefore, the HTML output is different each time, but always incomplete and wrong.
A really useless tool, just like expected. A Pi 4 is much too slow to capture data fast enough. In theory it might work with a really slow initiator and/or target, but this is not a realistic scenario.

The VAXstation uses the NCR5380, so it's fairly slow. And, or course, the tape read is a lot slower than disk.

If you think you can extract meaningful data with scsimon, these data should help with #111. My Ataris also have a 5380, and the transfers are faster than what you can capture with a Pi.

OK. I did the mount and list using S2P  (combined log):
mount&list.txt
mount&list script.txt
then I mounted the tape on S2P, and listed on the real tape drive. This worked. No logs because it will be the same as previous.
then I mounted the tape on the real drive, and listed on the S2P drive.
list no mount.txt
list no mount script.txt
It still asks for the 90 byte block regardless of where the mount is done.
Works on the real drive, fails on S2P.

Thank you. For the sake of completeless: Please list with s2p (you can re-start s2p before the operation so that only the list operation is part of the generated script), then run the script on trace level against your real drive.

I ran the following script against the real drive:
-i 3 -L trace
-c 12:00:00:00:ff:00
-c 00:00:00:00:00:00
-c 01:00:00:00:00:00 -o 90
-c 08:00:00:00:5A:00 -o 90

Results:
real.txt

Can you please run a modified script:
-i 3 -L trace
-c 12:00:00:00:ff:00
-c 00:00:00:00:00:00
-c 01:00:00:00:00:00 -o 90
-c 08:00:00:00:5A:00 -o 90
-c 03:00:00:00:ff:00

Yes, I thought it was interesting that it reported an error, then produced the data. Yes the READ POSITION is missing in the other log. Don't know why.
One interesting thing I notice was that when I mounted the tape on S2P and then listed on the real drive, the list was of the second file on the tape, so apparently the tape position is not at the beginning of the tape when you insert the tape. Not an issue, because the mount normally does the rewind.
Anyway, results of your modified script:
real2.txt

Reporting an error (to be more precise: CHECK CONDITION means there is a condition to check, usually an error, but not necessarily) and nevertheless sending data is something we have not seen before, have we?
Can you please run one more test with this script, and before doing that please switch your drive off and on:
-i 3 -L trace
-c 00:00:00:00:00:00
-c 12:00:00:00:ff:00
-c 00:00:00:00:00:00
-c 01:00:00:00:00:00 -o 90
-c 08:00:00:00:5A:00 -o 90
-c 03:00:00:00:ff:00
-c 03:00:00:00:ff:00

Yes, I thought we had done similar stuff before. Maybe you have enhanced the logging for s2pexec?
It makes sense that the drive returns the data, because the operating system is happy with what is returned.
real3.txt

While waiting for the result of this test I have re-read the specification and the manual of your drive. I have not found anything explicit yet, but it looks to me as if BOTH of these two things may happen: The drive reports CHECK CONDITION (and reports the difference between the actual and the requested block size) AND returns the available data. In this case it returns 80 bytes even though 90 were requested and at the same time reports the mismatch.
The improved logging of s2pexec and the last test seem to confirm that. And that may actually be the resolution of the problem we are facing: s2p currently either returns the data (if there is no mismatch) OR reports check condition. But not both.

Thank you for the latest log. By assuming that CHECK CONDITION can be reported and nevertheless the available data are returned everything that we have stumbled upon can be explained. Very good!
I will update s2p accordingly, but I am not sure yet whether this is a simple change or a more complicated one.

The boot code is fairly simple (cut down) being part of the BIOS ROM, so maybe it just requests 512 bytes because this is about as big as it gets (disks, CD-ROMs etc), then adjusts based on the CHECK CONDITION? Pure speculation as there is probably no source listings out there and I'm not into decoding machine language!  As mentioned before the 90 byte request may be a quick and dirty way of checking the tape is ANSI formatted.
I think we're close to getting this fully working now...

OK, please update your sources and re-try. Note that I have done what I usually don't do: Added an untested work-around. This might not work, and it will need refactoring, but maybe you can give it a try nevertheless.
Yes, I agree that we are quite likely close to the solution.

Nope, no go. Data looks misaligned to me. Also shouldnt you return 80 bytes and not 90?
test.txt

Indeed. Well, in order to do this correctly I will have to invest a bit more time ;-).

But maybe you can run one more test with your drive. I would like to see what it does if less data than available are requested.
-i 3 -L trace
-c 00:00:00:00:00:00
-c 12:00:00:00:ff:00
-c 00:00:00:00:00:00
-c 01:00:00:00:00:00 -o 90
-c 08:00:00:00:4A:00 -o 90
-c 03:00:00:00:ff:00

Looks like the latter...
test2.txt

Yes, it does. At least it is clear now what has to happen in case of a block size mismatch.

I'll probably be around another hour if that helps, otherwise see you tomorrow.

This change will take a bit longer, and the unit tests also have to be updated. I will be away over the weekend, i.e. this may take until Monday. See you!

No problem - thanks for all your effort.

Now that I know what to look for I found the matching part of the specification:
"A successful READ (6) command (i.e., the command returns GOOD status or returns a CHECK CONDITION
status with the sense key set to RECOVERED ERROR or COMPLETED) with a FIXED bit set to one shall transfer
the requested transfer length times the current block length in bytes to the application client. A successful
READ (6) command with a FIXED bit set to zero shall transfer the requested transfer length in bytes to the
application client. Upon completion, the logical position shall be after the last logical block transferred (i.e.,
end of partition side)."

"GOOD status or returns a CHECK CONDITION status with the sense key set to RECOVERED ERROR or COMPLETED", the OR is the important part.

Build dbaee85
You will be pleased to hear that the Backup/list function now works correctly!
Looking at the logs, the OS requests the 90 byte block 3 times - the VOL1, HDR1 and HDR2 blocks before the tape mark. This is the minimum requirement for an ANSI formatted tape, so I assume that is the test that it is doing. ie make sure that the first 3 blocks are 80 bytes with the right headers. After that it just dumps all the required data.
I am yet to get the boot from tape working. Not sure what is going on, but it doesn't work with the real DAT drive either (S2P now gets stuck at the same stage which is promising). I'm also having an issue with the DLT drive reporting parity errors - need to investigate that.

Another log for you to look at....
In this case, I am doing an installation from tape to disk. I have booted off CD-ROM as the tape boot doesnt work for some reason. The first step is to restore the image of a disk from a file on the tape (VMS054.B). A few errors in there.
I then went and did the same operation from a real tape (which worked), then proceeded with the installation (with S2P connected), but got similar errors relating to spacing.
restore.txt

I finally got my DLT drive working after running the cleaning tape about 6 times!
I can actually boot a tape in this one. Don't know why the DAT and S2P don't work.
Have confirmed that it has exactly the same behaviour with requesting long and short blocks.

The restore text should work now. There was a case where the tape position was not yet calculated correctlly.

That fixed it!
As a test, I have installed the whole operating system from tape - and it works!
The only thing I can't do now is boot from tape. Don't know what is happening here.  The physical DAT drive also fails to boot, but the TZ87 boot successfully.

This means that currently there are no open issues related to s2p, correct?

Yep, pretty much - unless you want to help me track down why I can't boot a tape. I don't know why one drive works and the other doesn't. Maybe some of the status returned is different.

I suggest to run a script from a working s2p boot process against the drive that does not work. This should reveal difference between the working and the non-working boot process.
Regarding this ticket. looks as if it can be closed.
You may remember that I mentioned https://github.com/PiSCSI/piscsi/issues/479 some time ago. Any chance that you can test this scenario? s2p has an improved READ/WRITE LONG, maybe it just works now. In case it does not, would you help with testing? Testing would be very similar to what you already know, i.e. with using s2pexec scripts.
The current READ/WRITE LONG implementation is compatible with what one of my hard drives does.

I'm not sure if the DAT drive ever worked (although I'm sure I would have done this 25+ years ago, but probably not on this exact model drive). The TZ87 (DLT) drive does work and boots off tape. It would be nice to get s2p to emulate this so that I can show that the whole process can be done from tape (for the installation of the OS, I had to boot off a CD-ROM to get the tape install running). The strange thing is that the failed boot does read plenty from the tape before it just hangs.
I can test the READ/WRITE LONG stuff - I just have to get my head around how to do it again. I might have a bluescsi image that I was testing with since I implemented the read/write long stuff on bluescsi in order to test volume shadowing (mirroring).
I am currently doing an installation of Ultrix  (A UNIX variant). This needed modification of bluescsi to work as it used a few SCSI commands that weren't catered for at the time. I'm happy to report that the installation is working fine so far

There should not be anything special s2p would have to emulate. s2p is (hopefully) compliant with the SCSI specs, i.e. it should be able to emulate any SCSI-compliant drive. I have never added (except for testing) anything drive-specific. It's all standard.
If the OS requests something else than 520 this should not matter. Just like with the tape drive, s2p reports the size difference, so that the OS knows the actual byte count that will work.
Regarding Ultrix, in case of any issues please open a new ticket.

By the way, in case you have a USB drive, maybe just for fun you can test whether your workstation can accesss it with the new SCSI-to-USB bridge. I have tested this with my hardware, of course, but maybe with your more exotic hardware it is different. See https://www.scsi2pi.net/en/scsi_to_usb.html for details.

Ultrix installs and boots fine. I just mentioned this because Ultrix uses some different commands to your normal Mac or VMS systems. Anyway s2p passes this test fine. I don't really know how to drive Ultrix, but install & boot + a few generic commands are all good.
I created a fork of bluescsi long ago to add the read/write long commands. I never added them back to the base as there were major changes being made to the code structure at the time, and it was all too hard! It was fairly simple to do, and seems to keep VMS happy.
I'm not familiar with your USB bridge. The VAXstation certainly has no USB support, and VMS is not UNIX based.

This should not matter for the bridge. One can simply connect a USB drive or USB stick etc. then create a device of type SCSG (https://www.scsi2pi.net/en/scsi_to_usb.html), and that's it. The USB drive should then behave like a SCSI hard drive.

So how is this different to just mounting the USB drive as part of the file system on the Pi? Or is this what is done? Or does it use the USB stick raw?

It uses it raw, all commands are directly passed through. This also gives access to commands s2p does not support. It even works with a CD-ROM and audio commands, even though the transfer rate is not good enough for having uninterrupted audio playback.


Error with compiling code

When attempting to compile I was first greeted with the following:
Microsoft (R) Build Engine version <IP_ADDRESS>72 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 74.92 ms for /Users/adamshort/Desktop/Code/collaboro/ice/ICE/ICE.csproj.
  ICE -> /Users/adamshort/Desktop/Code/collaboro/ice/ICE/bin/Debug/netstandard2.0/bin/ICE.dll
  No executable found matching command "dotnet-/Users/adamshort/.nuget/packages/functionmonkey.compiler/0.11.0-beta000/build/netstandard1.0/..\..\tools\netcoreapp2.0\FunctionMonkey.Compiler.dll"
/Users/adamshort/.nuget/packages/functionmonkey.compiler/0.11.0-beta000/build/netstandard1.0/FunctionMonkey.Compiler.targets(10,5): error MSB3073: The command "dotnet "/Users/adamshort/.nuget/packages/functionmonkey.compiler/0.11.0-beta000/build/netstandard1.0/..\..\tools\netcoreapp2.0\FunctionMonkey.Compiler.dll" "/Users/adamshort/Desktop/Code/collaboro/ice/ICE/bin/Debug/netstandard2.0/bin/ICE.dll"" exited with code 1. [/Users/adamshort/Desktop/Code/collaboro/ice/ICE/ICE.csproj]

Build FAILED.

/Users/adamshort/.nuget/packages/functionmonkey.compiler/0.11.0-beta000/build/netstandard1.0/FunctionMonkey.Compiler.targets(10,5): error MSB3073: The command "dotnet "/Users/adamshort/.nuget/packages/functionmonkey.compiler/0.11.0-beta000/build/netstandard1.0/..\..\tools\netcoreapp2.0\FunctionMonkey.Compiler.dll" "/Users/adamshort/Desktop/Code/collaboro/ice/ICE/bin/Debug/netstandard2.0/bin/ICE.dll"" exited with code 1. [/Users/adamshort/Desktop/Code/collaboro/ice/ICE/ICE.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:03.83

After a bit of digging around, I found that inside of netstandard1.0/FunctionMonkey.Compiler.targets I was specifying this path with:
    <FunctionCompilerExe Condition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp' OR '$(TargetFrameworkIdentifier)' == '.NETStandard'">dotnet "$(MSBuildThisFileDirectory)..\..\tools\netcoreapp2.0\FunctionMonkey.Compiler.dll"</FunctionCompilerExe>

Surprisingly, the direction of those slashes was actually important - when I reversed them, I located the DLL correctly (I verified in the terminal that it was in fact at that location too)
    <FunctionCompilerExe Condition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp' OR '$(TargetFrameworkIdentifier)' == '.NETStandard'">dotnet "$(MSBuildThisFileDirectory)../../tools/netcoreapp2.0/FunctionMonkey.Compiler.dll"</FunctionCompilerExe>

However, this might of fixed that issue but it uncovered a much more troublesome issue that I can't fix.
Microsoft (R) Build Engine version <IP_ADDRESS>72 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 66.52 ms for /Users/adamshort/Desktop/Code/collaboro/ice/ICE/ICE.csproj.
  ICE -> /Users/adamshort/Desktop/Code/collaboro/ice/ICE/bin/Debug/netstandard2.0/bin/ICE.dll

  Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
     at FunctionMonkey.ConfigurationLocator.FindConfiguration(Assembly assembly) in D:\wip\myOpenSource\functionMonkey\Source\FunctionMonkey\ConfigurationLocator.cs:line 95
     at FunctionMonkey.Compiler.Implementation.FunctionCompiler.Compile() in D:\wip\myOpenSource\functionMonkey\Source\FunctionMonkey.Compiler\Implementation\FunctionCompiler.cs:line 56
     at FunctionMonkey.Compiler.Program.Main(String[] args) in D:\wip\myOpenSource\functionMonkey\Source\FunctionMonkey.Compiler\Program.cs:line 44
  /var/folders/ws/8qmgsd2d5qzgk18kqcr5tgb80000gn/T/tmp76d75810b305435184c34e47eb5e1137.exec.cmd: line 2: 39374 Abort trap: 6           dotnet "/Users/adamshort/.nuget/packages/functionmonkey.compiler/0.11.0-beta000/build/netstandard1.0/../../tools/netcoreapp2.0/FunctionMonkey.Compiler.dll" "/Users/adamshort/Desktop/Code/collaboro/ice/ICE/bin/Debug/netstandard2.0/bin/ICE.dll"
/Users/adamshort/.nuget/packages/functionmonkey.compiler/0.11.0-beta000/build/netstandard1.0/FunctionMonkey.Compiler.targets(10,5): error MSB3073: The command "dotnet "/Users/adamshort/.nuget/packages/functionmonkey.compiler/0.11.0-beta000/build/netstandard1.0/../../tools/netcoreapp2.0/FunctionMonkey.Compiler.dll" "/Users/adamshort/Desktop/Code/collaboro/ice/ICE/bin/Debug/netstandard2.0/bin/ICE.dll"" exited with code 134. [/Users/adamshort/Desktop/Code/collaboro/ice/ICE/ICE.csproj]

Build FAILED.

/Users/adamshort/.nuget/packages/functionmonkey.compiler/0.11.0-beta000/build/netstandard1.0/FunctionMonkey.Compiler.targets(10,5): error MSB3073: The command "dotnet "/Users/adamshort/.nuget/packages/functionmonkey.compiler/0.11.0-beta000/build/netstandard1.0/../../tools/netcoreapp2.0/FunctionMonkey.Compiler.dll" "/Users/adamshort/Desktop/Code/collaboro/ice/ICE/bin/Debug/netstandard2.0/bin/ICE.dll"" exited with code 134. [/Users/adamshort/Desktop/Code/collaboro/ice/ICE/ICE.csproj]
    0 Warning(s)
    1 Error(s)

If you need any details I will happily provide. I am building a production system using this platform as I actually was going to build all of this myself before I stumbled upon the framework thanks to a tip from a mate (how lucky!!!).
Happy to help however I can! The only potential thing I can think of is that my DLL resides within netstandard2.0, while FM.Compiler seems to be in netstandard1.0?

First - thanks for the detailed error report, I'm looking at this now. I believe I have a resolution for the path issue and the second issue is connected to some sort of assembly loading problem which is missing type information in the exception. I'll get those resolved now and while I don't think that will fix the second problem hopefully it will give us more insight.
If its still opaque at that point then I can outline how to debug FunctionMonkey (its pretty easy) and we can maybe do a screen share or share source. Whatever works best!

Fantastic! That would be awesome. Yeah, I am super happy to debug FM, sounds great!

A couple of new NuGet packages should be available (FunctionMonkey 0.12.1 and FunctionMonkey.Compiler 0.12.1) - could you give those a go and let me know what you find please?
The FunctionMonkeyCompilerExe property in the target file should now use / on Unix based platforms (I've not been able to try that - I do have a Mac but not with me at the moment, I've only used FunctionMonkey in "debug" mode on it so obviously this is something I need to start looking at more closely now!).
And I've put some belt and braces around the error handler for the assembly load exception. Seems its getting a null type I didn't expect.
I'm just writing up some compile and debug notes as part of the main documentation now - ought to be there anyhow.

Also, I can confirm that Microsoft.WindowsAzure.Storage.dll is in fact in netstandard2.0/bin.

Thanks!
The issue is to do with the version of the Microsoft.WindowsAzure.Storage assembly - because Azure Functions runs your code in process and how the extensions worked you had to match the specific versions of assemblies that the runtime was using. Severely limiting.
Fortunately they've been working on improving this but the Storage assembly is the last one to be addressed. There's some more info here:
https://github.com/Azure/Azure-Functions/issues/821
They are literally about to roll out updates to resolve this:
https://github.com/Azure/app-service-announcements/issues/129
https://github.com/Azure/app-service-announcements-discussions/issues/64
In the meantime you basically need to make sure you reference (and your dependencies reference or are compatible with) 8.6.0.
As soon as the new NuGet package is released (tonight I believe) I'll update the Function Monkey assemblies to match.
If you're interested in debugging Function Monkey / working on it / exploring it I've published some guidance over here:
https://functionmonkey.azurefromthetrenches.com/guides/contributing/debugging.html
Hopefully useful!

 Thank you for all your help!
Thanks for the guidance doc too,  super interested in working on the framework. Cheers!

Thanks for your help in getting to the bottom of it and feedback, much appreciated!
I'll close this now but do let me know if you have any further issues.


Disallow @everyone and @here mentions for /ptal

/ptal should not allow @everyone or @here mentions, but user and role mentions are valid
/tweet should allow only role mentions

/tweet doesn't need any specific mention overrides right? The command takes no user input and therefore can't be used to mention anyone. If we want to be explicit, should we be explicit for every command?
Do we want to limit /ptal to specific roles?

That's right. /tweet probably shouldn't need explicit settings since the default is for everything to be allowed, but it's currently does not trigger notifications for the @mention using that role. I was hoping to see if this helped!
I don't think /ptal needs to be explicit about the particular allowed roles. It's only available to maintainers so there's not a huge risk of abuse. I'd rather be permissive than try to keep these in sync with any future role adjustments.

It turns out that allowed_mentions should be explicitely set for the /tweet command. What I am unsure of is to what roles /ptal is limited. My alt account has support-patrol and is able to use it, but that might be because it has that role.


Minor fixes. New docker image v2.2.4

:tada: This PR is included in version 2.2.5 :tada:
Your semantic-release bot :package::rocket:


[bug] Facility type dropdown missing

index and give used to have a facility type dropdown so you could filter by facility type. That seems to be missing currently, which I believe is a bug.

In case this is a user specific bug
Browsers: tested on chrome and firefox

CC @tinabeans please check the design of the fix!

@linderr the design of the fix is identical to how it was before it disappeared (it didn't actually get removed and added, the parsing of organization type from our dataset got broken)

Perfect!!! @ngottlieb


dynamic link with custom domain doesn't work with the first launch of the application after iOS Application installed

[REQUIRED] Step 2: Describe your environment

Xcode version: 10.2.1
Firebase SDK version: 4.13.0
Firebase Component:  Core, Database, Firestore, Messaging, Storage, etc)
Component version: Core - 4.0.20, FirebaseDynamicLinks - 2.3.2

[REQUIRED] Step 3: Describe the problem
First, I connected my domain in Firebase Hosting and created Dynamic Links with a custom domain.
I set up my firebase dynamic links for iOS application step by step with the official tutorial. The link works as expected except in one case. When the application is not installed, a transition occurs in the AppStore, the application is installed, but when it is opened, the function application: openURL: options: is not called (Deployment target 9.3). As a result, it is impossible to call the necessary code when you first open the application after installing it by link.
But same code work in the case, when I use standard firebase suffix domain (xxx.page.link). Codebase and parameters of link do not change in this case, only link suffix (from custom to standard)
Steps to reproduce:

Create a dynamic link with the custom domain in the firebase console.
Setup iOS application for this link.
Remove application
Go to created dynamic link
Go to AppStore
Install application from XCode, simulating installation from AppStore.
Open app.

Relevant Code:
Output of dynamic link diagnostic:
---- Firebase Dynamic Links diagnostic output start ----
Firebase Dynamic Links framework version 2.3.2
System information: OS iOS, OS version 12.3.1, model iPhone
Current date 2019-07-18 09:39:44 +0000
Device locale en-US (raw en_US), timezone Europe/Moscow
	Specified custom URL scheme is com.xxx.XXX and Info.plist contains such scheme in CFBundleURLTypes key.
	AppID Prefix: P6A385CN94, Team ID: P6A385CN94, AppId Prefix equal to Team ID: YES
performDiagnostic completed successfully! No errors found.
---- Firebase Dynamic Links diagnostic output end ----

Debug mode of dynamic link give only one warning:
There is no configuration to prevent phishing on this domain. Setup URL patterns to whitelist in the Firebase Dynamic Links console.

apple-app-site-association file exists and meets requirements
{"applinks":{"apps":[],"details":[{"appID":"P6A385CN94.com.xxx.XXX","paths":["NOT /_/*","/*"]}]}}

@AJereli Thanks for the report. Please try a more recent version of Firebase. The version you're using is a year and a half old and the latest is now Firebase 6.4.0.

@paulb777
Seem like a can't update this pod. Can it be related to that I use obj-c project?

@AJereli It's likely related to something in your Podfile that doesn't work with Firebase 6. You can see the details by examining the generated Podfile.lock.


Shortcut copy button of the code block still not working on version chainlit 1.0.100

Shortcut copy button of the code block still not working on version chainlit 1.0.100

What browser do you use? I can't reproduce

@willydouhard  Google Chrome on Mac OS

The clipboard feature needs either a localhost url, or an HTTPS url, this is a browser limitation.

The clipboard feature needs either a localhost url, or an HTTPS url, this is a browser limitation.

Thanks!  I have configured https service, and it works fine now.


🌱 Making workflows not run on forks.

This PR is making sure that github workflows only run on upstream repo and not on forks.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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 75.192%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2058

Relevant Lines:
2737

💛  - Coveralls

Hi @adilGhaffarDev thanks for the PR!
question instead can you just disable the github actions in your fork?

Hi @adilGhaffarDev thanks for the PR! question instead can you just disable the github actions in your fork?

My 2 cents: It makes no sense for fork to try push their images to upstream repository, so wouldn't it make more sense to disable that kind of workflow here than each individual fork doing it? This PR is not disabling build and test type workflows.

Can we get the stuck Mellanox action retriggered to get this merged? Its been pending a long while... @SchSeba

Hi @tuminoid that lane is not critical we are just waiting for another maintainer to approve so we can merge that is the policy
cc @Eoghan1232 @e0ne

Hi @tuminoid that lane is not critical we are just waiting for another maintainer to approve so we can merge that is the policy
cc @Eoghan1232 @e0ne

Oh, ok. GH shows its ready to go, so I guess there is no actual branch protection configured, but just agreed policy? Thanks!

That is right

@Eoghan1232 @SchSeba @adrianchiris can we merge this one?


Style admin page

Make things look and work a lot better!

I think you have to tell the app.json about the new env variable.

🚢

💯


Fairing collider doesn't have enough polygons with only 1 faring node

I don't know how to show collider mesh in ksp (I read that unity editor has this feature, but you can't do it running outside of it?), hopefully these FAR voxels show the issue. The colliders are actually like this  (not a FAR bug), I tried pushing it with a kerbal and the cylinder gets rotated like it's a square.
The attachment node are is on the right:

With 2 nodes it also looks rough:

version <IP_ADDRESS>
ksp 1.4.5

Oh and yes you can walk through the left side:


Debug build setting not passed to CMake build config in Conda-forge

Hi,
I've been searching through the documentation at conda-forge, scikit-build, scikit-build-core, CMake, StackOverflow, and I feel like I'm very close to finding an answer, but I'd like to know for certain whether this is an issue with the build engine, my configuration, the conda-forge configuration or something else.
Background
I have a Python package (raven-hydro) that is a relatively simple wrapper for a binary written in C++ (RavenHydroFramework). The Python package has been using scikit-build-core for a while now, and it has been working very well. I have been able to cross-compile things very easily. Thanks again for this great tool!
Now, the latest version of RavenHydroFramework must be compiled in with -DCMAKE_BUILD_TYPE=Debug. Getting this to work for PyPI-based packages has been very simple:
[tool.scikit-build.cmake]
build-type = "Debug"

Problem
This package is also on conda-forge, and in previous versions, there were zero issues building for macOS/Windows/Linux. According to the conda-forge documentation, several CMAKE_ARGS are set on environment activation. This shouldn't be an issue, as the arguments passed to CMake from Python should override these settings. Unfortunately, that hasn't been my experience.
Despite the fact that the build logs on the conda-forge Azure pipelines showing messages that give me the impression that the CMAKE_BUILD_TYPE from the environment is being ignored, e.g.
raven-hydro_1709925961683/_build_env/bin/x86_64-conda-linux-gnu-strip', '-DCMAKE_BUILD_TYPE=Release', '-DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER', '-DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY', '-DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY', '-DCMAKE_FIND_ROOT_PATH=/home/conda/feedstock_root/build_artifacts/raven-hydro_1709925961683/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold;/home/conda/feedstock_root/build_artifacts/raven-hydro_1709925961683/_build_env/x86_64-conda-linux-gnu/sysroot', '-DCMAKE_INSTALL_PREFIX=/home/conda/feedstock_root/build_artifacts/raven-hydro_1709925961683/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold', '-DCMAKE_INSTALL_LIBDIR=lib', '-DCMAKE_PROGRAM_PATH=/home/conda/feedstock_root/build_artifacts/raven-hydro_1709925961683/_build_env/bin;/home/conda/feedstock_root/build_artifacts/raven-hydro_1709925961683/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/bin']
2024-03-08T19:28:36.3745077Z   2024-03-08 19:28:36,346 - scikit_build_core - WARNING - Unsupported CMAKE_ARGS ignored: -DCMAKE_BUILD_TYPE=Release

My package still doesn't seem to build with the proper CMAKE_BUILD_TYPE flag set. Oddly enough, this issue isn't occurring across all platforms; On Windows, it would appear the mechanisms are working as intended, and I believe this may have something to do with the fact that scikit-build-core passes configuration commands to CMake/MSVC via a different process than used for macOS and Linux (if I understand correctly).
I've traced the issue to one line that gives me the impression that the configurations are not being translated 100% to the underlying CMake call.
Conda-forge Windows build log:
2024-03-08T19:36:49.0016833Z   *** Building project with Visual Studio 17 2022...
2024-03-08T19:36:49.0017720Z   2024-03-08 19:36:48,986 - scikit_build_core - DEBUG - RUNENV - changes since last run only:
2024-03-08T19:36:49.0018569Z
2024-03-08T19:36:49.0019587Z   2024-03-08 19:36:48,986 - scikit_build_core - INFO - RUN: D:\bld\raven-hydro_1709926259969\_build_env\Library\bin\cmake.EXE --build build -v --config Debug

Conda-forge macOS build log:
2024-03-08T19:38:16.5143560Z   *** Building project with Unix Makefiles...
2024-03-08T19:38:16.5146150Z   2024-03-08 19:38:16,511 - scikit_build_core - DEBUG - RUNENV - changes since last run only:
2024-03-08T19:38:16.5147020Z
2024-03-08T19:38:16.5148350Z   2024-03-08 19:38:16,511 - scikit_build_core - INFO - RUN: /Users/runner/miniforge3/conda-bld/raven-hydro_1709926231787/_build_env/bin/cmake --build build -v

Conda-forge Linux build log:
2024-03-08T19:28:37.0290022Z   *** Building project with Unix Makefiles...
2024-03-08T19:28:37.0295585Z   2024-03-08 19:28:37,027 - scikit_build_core - DEBUG - RUNENV - changes since last run only:
2024-03-08T19:28:37.0300370Z
2024-03-08T19:28:37.0306218Z   2024-03-08 19:28:37,027 - scikit_build_core - INFO - RUN: /home/conda/feedstock_root/build_artifacts/raven-hydro_1709925961683/_build_env/bin/cmake --build build -v

Questions

Am I correct in believing that arguments set within the [tool.scikit-build.cmake.define] block can override the environment variables set by conda-forge?

For context, in addition to setting  [tool.scikit-build.cmake] build-type = "Debug", I've also set the following to be certain that my build configuration is being seen by CMake:

pyproject.toml:
[tool.scikit-build.cmake.define]
CMAKE_BUILD_TYPE = {env="RAVEN_HYDRO_CMAKE_BUILD_TYPE", Default="Debug"}

CMakeLists.txt:
# Set default build type in CMake if skbuild is set
message(STATUS "CMAKE_BUILD_TYPE set to '${CMAKE_BUILD_TYPE}'")

Is there a functional difference between setting CMake flags via pyproject.toml, via the CLI, or environment variables when it comes to these flags being passed along to build functions spawned by pip/scikit-build-core? Is one method more persistent/permanent than another? What is the priority order when it comes to these methods?

What would you suggest is the best way to ensure that --config Debug is passed to CMake on conda-forge?

Additional Information
raven-hydro testing branch: https://github.com/Ouranosinc/raven-hydro/pull/36
raven-hydro testpypi dev package: https://test.pypi.org/project/raven-hydro/0.3.1.dev0/
conda-forge pull request (currently using v0.3.1-dev): https://github.com/conda-forge/raven-hydro-feedstock/pull/25

A quick comment: Yes, the process is different between Windows and Unix. Specifically, it's actually based on the generator - multi-config generators (default on Windows) have the flags you are seeing. You can use a higher verbosity level to see the full file of presets that is passed to CMake.
I'll try to look into this soon, before next release.

I see -DCMAKE_BUILD_TYPE:STRING=Debug in the configure line for Unix in your logs. It seems to be filtering it from CMAKE_ARGS and setting it in the configure step. You are getting undefined reference to ExitGracefully, is that related to the build type?

Where are you linking to the RavenHydroFramework library or including that in your build? I see you adding that to an executable, but not to the Python target. ExitGracefully is defined there. When you build normally, you won't notice that, since Python extension modules usually ignore missing symbols when building on Unix[^1]. But I'd guess conda-build is checking for missing symbols?
[^1]: There's a way to do this, but it's tricky and we've never set it up for pybind11. It's in nanobind though. You basically have to give the compiler the list of symbols without linking to the binary so it can detect any missing symbols not in the list.

@henryiii Thanks for taking the time to look this over!

I see -DCMAKE_BUILD_TYPE:STRING=Debug in the configure line for Unix in your logs. It seems to be filtering it from CMAKE_ARGS and setting it in the configure step, as is correct for single config generators. You are getting undefined reference to ExitGracefully, is that related to the build type?

Unfortunately, yes. The build type has an impact on the availability of the functions. I'm not an expert in C/C++ but for the time being, the only way to build the executable is in debug mode. The source code for the project can be found here (Relevant issue: https://github.com/CSHS-CWRA/RavenHydroFramework/issues/24). I'm not sure how challenging it would be to ensure that the missing symbols are carried over to the release build.

Where are you linking to the RavenHydroFramework library or including that in your build? I see you adding that to an executable, but not to the Python target. ExitGracefully is defined there. When you build normally, you won't notice that, since Python extension modules usually ignore missing symbols when building on Unix. But I'd guess conda-build is checking for missing symbols?

The library is fetched via git and the source file that performs the linking with Pybind11 can be found here. There are plans to eventually link some functionality at a library level, but the work is very early in development. I wish I knew more about the conda-forge internals, but I'm already out of my depth.


[GHSA-h3qr-39j9-4r5v] Data written to GitHub Actions Cache may expose secrets

Updates

Affected products

Comments
The advisory on the affected repository was updated to include v2 already: https://github.com/gradle/gradle-build-action/security/advisories/GHSA-h3qr-39j9-4r5v

Hi there @bigdaz! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.
This change will be reviewed by our highly-trained Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

Sadly I can't accept this PR as it would be an invalid version. There's a public discussion post about this issue here
https://github.com/orgs/community/discussions/54553
And I'll ping again on our internal tracking issue.

Thanks @darakian . We'll be releasing gradle-build-action@v3 in the coming weeks, and that should finally allow the security alert to be resolved via conventional upgrade.

Thanks @darakian . We'll be releasing gradle-build-action@v3 in the coming weeks, and that should finally allow the security alert to be resolved via conventional upgrade.

Right on. Sorry for the lack of traction on getting this version matching working correctly too 😞

👋 This pull request has been marked as stale because it has been open with no activity.  If you do nothing this pull request will be closed eventually by the stale bot. Please see CONTRIBUTING.md for more policy details.

A fix for actions versioning issues has shipped
https://github.com/orgs/community/discussions/54553
So, I'll just close this PR out 👍


Add grab to overrides

It actually has the Python 3.4 classifier set: https://github.com/lorien/grab/blob/9bf381993a6862a3413f5e1d3439ff1301260d62/setup.py#L25
Not sure why it didn't show up in pypi.

Thanks!
As for why it hasn't shown up on PyPI, they probably forgot to push the new metadata (it's a separate step if you don't use twine). If you feel up for it I would  file a bug with the project.

Thanks a lot! That's would be nice~


Update new-teams-desktop-admin.md

Change incorrect date from 2023 to 2024

@JoanneHendrickson
PR has been copyedited and is ready for final review, could you please check and merge? Thanks!

@JoanneHendrickson
PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


[FLINK-33694][gs-fs-hadoop] Support overriding GCS root URL

What is the purpose of the change
This change configures the the GCS client used by the GSFileSystem's RecoverableWriter codepath to use the same GCS root URL as used by Hadoop.
Without this change, the GSFileSystem behaves differently depending on context if this config option is set—for instance, FileSource will use the overridden URL while FileSink will not.
Brief change log

Update GSFileSystemFactory/GSFileSystemOptions to look for the gs.storage.root.url Flink config option, overriding the GCS client's Host option if it is set

Verifying this change

Added one test to ensure the GCS SDK Storage client's Host option is overridden when the gs.storage.root.url Flink config option is set
Built the plugin and used it with an otherwise-vanilla Flink deployment and successfully used FileSink to write to an instance of fake-gcs-server

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable (previously-documented behavior for overriding the GCS root URL was not actually supported, but will be with this change)

Once this is accepted, I am ready with backport branches for 1.18 and 1.17.

@flinkbot run azure

I considered a slightly different approach, delegating the lookup of the config option to the GCS Hadoop connector itself: https://github.com/apache/flink/compare/master...patricklucas:flink:FLINK-33694_gs_fs_host_v2
If I get some feedback about which of these options is preferred, I can update the PR accordingly.

@XComp before this becomes a dead PR, do you know whom might be a good candidate to ask for a review?

@afedulov do you have capacity to review this PR?

@patricklucas My understanding is that one would typically want to override fs.gs.storage.root.url only in very specific scenarios, such as the one you mentioned with fake-gcs-server. I would like to understand if this change could lead to unexpected consequences for Flink GCS users. It appears that:

Users are likely to have the fs.gs.storage.root.url parameter set only in rare cases.
If it is set, they probably expect both the GCS source and GCS sink to use the URL.

Is this assessment accurate?

@afedulov it is quite popular to use alternate endpoint URLs for blob storage services with S3, less so for GCS. I would actually expect it to be more popular, as testing jobs that interact with blob storage without actually having to read/write over the internet is desirable, but it's clearly not so common with Flink else others would have hit this.
But yes, the main issue is the inconsistent behavior: Flink relies on Hadoop's filesystem implementations in many cases, and they can be configured using the Hadoop configuration options. However, Flink has chosen to use its own custom implementations in certain cases but has not ensured they can be configured the same way. A user would reasonably expect they can use the Hadoop configuration options to configure this Flink FS impl (which has "Hadoop" in the name), but in fact nearly no configuration options for the write codepath are exposed.

I do not think there is much room for unexpected behavior here. The surface area of the change is quite small and follows the existing model for translating a Hadoop config option specific to this filesystem implementation into its native SDK equivalent.

But yes, the main issue is the inconsistent behavior
The purpose is clear and I think it is a good idea to improve it. My only concern is a scenario like this:

A user has a pipeline that reads from some local GCS implementation and writes it into the actual cloud GCS(root GCS url configured via Hadoop). This works because the sink currently ignores this setting and defaults to the Google URL
Merging the proposed change unexpectedly breaks the pipeline because it loops data back into the local store instead of Google GCS.
Can we be confident that such does not exist in the wild?

My suspicion is that there's an extremely small chance of that but I have no way to quantify it.
In our case it was actually the other way around: we set this option and were reading and writing to GCS, however we were writing in a custom sink that used the GCS SDK directly, so everything worked as expected. It was only when we migrated to using the normal file sink that this issue arose.
Does the Flink project have guidelines to approaching fixing this sort of issue, where users may depend on a definitely-broken behavior? If we cannot fix it directly (before Flink 2.0, I assume), do you have a suggestion for another workaround—perhaps just a new config key altogether?

Sure. Could you provide backport PRs for 1.18 and 1.17? Then I can merge all the necessary PRs at once.

@XComp sure, coming up shortly.
Thanks for the review, @afedulov.


Linux: library updates IO resources usage can be optimized

I am using polaris for quite some time now without issues. (except manual updates on arch)
My music library consists mostly with mp3. In total it is about 40 GB on hard drive.
But when I left glances system monitoring tool overnight, it generated unpleasant report stating that that polaris periodically consumes a lot of IO bandwidth which slows my home server.
It would be great if in the feature we got smarter and greener update mechanism.

Take a look on reports on the bottom of screenshot.
I have syncthing also running on the same server. It is dealing with a lot more files, but never becomes a problem.

You should probably look into setting up the IO bandwidth controller (from cgroups) for polaris.
And as far as I can tell, those error messages mean that polaris and the others are waiting for the disk. So polaris and the VM get slowed down, not necessarily your whole system.

Yeah this is most likely caused by the periodic scan. The work to switch to filesystem watches instead is tracked in #5. It's been a while since I looked at the state of cross-platform libs for this so hopefully the situation has improved now.
In the meantime, you can also reduce the frequency of the collection scan from Settings -> Collection  in the web client.
Closing this as a dupe of the issue linked above but feel free to continue the discussion if needed.

It's been a while since I looked at the state of cross-platform libs for this so hopefully the situation has improved now.

In 2019 we've stopped using notify in rust-analyzer stopped because of some relatively rare 100% CPU usage reports on MacOS. Of course it might be in a better shape now, but it's not something I can test.

Thanks.


Use zap in activation package

Motivation
Like previous PRs replace custom log package with zap logger in activation.
Description
Replace go-spacemesh/log with zap in the activation package.
Test Plan
n/a
TODO

[x] Explain motivation or link existing issue(s)
[x] Test changes and document test plan
[x] Update documentation as needed
[x] Update changelog as needed

bors merge


Spring Cloud Azure support native images

Description
Resolves #31017.
This PR will enable the spring cloud azure libraries to build to native images. Spring Cloud Azure libraries rely on Azure SDKs, but the com.azure:azure-aot-graalvm-support is not compatible with the latest GraalVM SDK, see #32033, so this PR includes the reachability metadata of Azure SDKs in the spring-cloud-azure-service module.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.

/azp run java - spring - tests


Be Compliant with Zalando Open Source Rules

As per https://opensource.zalando.com/docs/releasing/index/#be-compliant we have some homework to do in order to be compliant with the rules of a Zalando open source project. Although we have effectively followed them, it makes sense to look into ways how we can enforce them more strictly.
The following rules we currently do not enforce by technical means:

Sign-off every commit - we currently allow unsigned commits to be pushed/merge into the main branch
Enforce code-reviews with at least 2 sets of Zalando eyes - we currently only require 1 set of Zalando eyes

We've agreed to stick with pr-opener plus 1 reviewer (via https://github.com/zalando/logbook/pull/1612). Commit signing has been turned on :heavy_check_mark:


broken, or unexpected required personal access token scope undocumented?

Plugin 1.0.2 on kanboard 1.2.0
I've created a personal access token and configured the plugin with my github username, and the token as the password. However, the integration does not work, returning "Github Issue not found." when I try to create a task with it.
I suspect a scope may need to be enabled, but this is not documented (or the plugin is outdated and just won't work with tokens as-is). I have attempted enabling all read-only scopes, in addition to the top level 'repo' scope, and had no luck.
Just in case, I have also tried this with a repository under my own account (vs inside my organization) and am still not able to use the plugin.

I would like to know, if there is anything new about this issue. Is it solved?

@draeath @k00ni all you need is repo:public_repo, that's the only and minimal scope that needs to be enabled.

Thanks for the hint @TheAssassin


Adjust Windows pagefile to avoid kubelet failures

@xandyzhangx ran into an issue where once some pods were scheduled, the kubelet & docker instances were up to 2GB+ and pagefile was exhausted.
We need an investigation to figure out what the right pagefile size is to avoid crashing the kubelet.
Also see #3999

/assign @andyzhangx

Here's how to query the current allocation and max used. I added it to my log collection script:
https://github.com/PatrickLang/logslurp/commit/f310e200ef54c754f07db3ec853a4a1a5dfc84c3


support for feedback service for inactive devices

Hi, I am newbie to GitHub, I don't know where to ask questions. Is there any support for Feedback service for inactive devices in your library? Thank you.

Is there any support for Feedback service for inactive devices in your library?

Not any more. Pushy uses the HTTP/2-based APNs API, which no longer has a feedback service. Using the new API, the APNs server will just tell us immediately if a notification couldn't be delivered because the token was expired. Please see the PushNotificationResponse docs for details.

but,If you send invalid token more than a certain amount, the  apn server will close the connection. it will slow down the speed of push system, how to do?

I'm sorry—I don't understand the question. Could you please rephrase?


Auto-detect which components are used as const and mut and generate the SystemContract accordingly

Should also support multiple components as arguments to the System

ⓎⒺⓈ


EntryXXXListener is not working on Turkish language Windows 10

Expected behavior
EntryXXXListener is working
Actual behavior
EntryXXXListener is not working on Turkish language Windows 10
You can read at https://mattryall.net/blog/the-infamous-turkish-locale-bug for more information.
Easiest fix will be changing toLowerCase() calls to toLowerCase(Locale.ENGLISH)
I guess problem comes from usage at CommandPubSubDecoder.java
Steps to reproduce or test case
You can force Turkish language by giving JVM argument -Duser.language=tr and try to use listeners on any map with name which includes character 'i'
Redis version
6.2.4
Redisson version
3.16.1
Redisson configuration
        Codec codec = new Kryo5Codec();
        Config config = new Config();
        config.setCodec(codec);
        config.useSingleServer().setAddress(this.redisURL);
        return Redisson.create(config);

The dreaded dotless i.


[WIP] logging: simplify and standardize logging setup and usage

Fixes issue #6704

The conflicts are from merging #6701.
@gnprice did you suggest the move to kwargs here?  I'm not totally sure it's helpful.

@timabbott he didn't. I probably should of added notes to this. The intention was to address how much configuration the create_logger and set_log_file will allow. If the logger and any handlers are not defined in config, then we trust in the defaults or the config can be done in create_logger and set_log_file. I'm actually a bit behind on the progress of the logging system, so it's probably best to scrap this.

@hollywoodno I like the commit 3db26cfb7, "move logger file handler setup to a function"! That would be a good start on its own.
I think the next steps I'd take after that would be

Convert the call sites of create_logger to call set_log_file themselves, and have create_logger stop doing it.
Replace the calls to create_logger with logging.getLogger and logger.setLevel, just like the inside of create_logger. Then delete create_logger.
Delete the setLevel calls where they're redundant -- this mostly means the INFO cases, but you'll want to compare against the settings in settings.py.

Then we'll have taken care of create_logger quite well, and reduced all our logging calls to a more uniform use of the standard API.
After that comes a cleanup that will help a lot in making our logs easy to read, and will involve a lot of small fixes in many places:

Convert all our calls to the log methods directly on the logging module, so that they log to a specific logger instead. This means logging.info(...) becomes logger.info(...), where logger will typically come from a logger = logging.getLogger(__name__) at the top of the module. We have about 200 of these in the codebase:

$ grep -rohE 'logging.(deb|inf|log|warn|err|exc|crit)\w*\(' */ | sort | uniq -c
      2 logging.critical(
      5 logging.debug(
     29 logging.error(
     13 logging.exception(
    104 logging.info(
      5 logging.warn(
     45 logging.warning(

Almost all of them will be easy to fix, and then there will probably be a small number that are tricky -- I'll be glad to help figure those out as we run across them.
The effect of this cleanup will be that log messages give a clear idea of where they're coming from, which can make debugging a lot easier! So I'm eager to see it happen.
Would you be up for trying these? Sorry for not giving very clear recommendations before -- hopefully this is more helpful.

I've just merged a series of commits (to cd5e44491) that do the create_logger part of this.

After that comes a cleanup that will help a lot in making our logs easy to read, and will involve a lot of small fixes in many places:

I'd still be quite interested in seeing this part happen!

Closing, since we've now done some other refactors to this system.  Thanks @hollywoodno!


Custom placeholder char

Adds a method to set a custom character for the placeholder item.

I can squash these two commits after review, if you'd like.

I'm glad it was relatively easy! No need to squash. Just bump the version code before you merge, I suppose, and then update the aar in our other project.
⭐

OK. I've bumped the version number and will update the project. However, you need to merge this since I don't have access to your repo (I did this in my own fork).


Plotting and animation

Are there any plans of porting over the plotting and animation code from ComplexNetworkSim? I'm willing to contribute.

Yes there is, but at the moment I'm cleaning up the code and making some aspects more Pythonic. Once the code base is stable then I can start working on additional features.
Though if you'd like to contribute porting the plotting code, then that would be great and very much appreciated.


fix(typo): framework

Description

What type of PR is this? (check all applicable)

[ ] 🍕 Feature
[ ] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[x] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Changing in one place might cause some issues in cli


Can we somehow have it track both v3 and v4 status

I have multiple LavaLink hosted of different versions v3 and v4 this code supports v4 but not v3 is there something by which we can make it support v3 too

Unfortunately it's not possible, but you can fetch both stats from v3 and v4 lavalink through HTTP requests. I'm not planning to update the code to make it support both v3 and v4, soon v3 lavalink will no longer maintain

You can still checkout the other branch as it supports lavalink v3

Печально, что это не поддерживает обе версии.

It's sad that it doesn't support both versions


Application attempted to call on a destroyed WebView

I got error code like this
java.lang.Throwable
at org.chromium.android_webview.AwContents.a(PG:355)
at org.chromium.android_webview.AwContents.b(PG:415)
at com.android.webview.chromium.WebViewChromium.loadUrl(PG:251)
at android.webkit.WebView.loadUrl(WebView.java:714)
at com.pierfrancescosoffritti.androidyoutubeplayer.core.player.views.WebViewYouTubePlayer$play$1.run(WebViewYouTubePlayer.kt:55)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6718)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
This happens after i programmatically remove the app and restart, will cause this everytime.

Hey, what do you mean with "programmatically remove the app and restart"?

Some code like this kinda
PackageManager pm = c.getPackageManager();
if (pm != null) {
Intent mStartActivity = pm.getLaunchIntentForPackage(
c.getPackageName()
);
if (mStartActivity != null) {
mStartActivity.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
int mPendingIntentId = 223344;
PendingIntent mPendingIntent = PendingIntent
.getActivity(c, mPendingIntentId, mStartActivity,
PendingIntent.FLAG_CANCEL_CURRENT);
AlarmManager mgr = (AlarmManager) c.getSystemService(Context.ALARM_SERVICE);
mgr.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + 100, mPendingIntent);
System.exit(0);
The reason behind this is because sometimes user close and app and it forget about it, as normal Android OS will GC the whole app, but not in all manufactures' phones, so we come up with a solution to force close the app and relaunch after some period of time.
Also sometimes normal kill or remove from app list, will cause the same problem, which don't allow the webview to launch and Youtube view won't load and play videos

same issue.

It's still not clear to me what this issue is about. The description of the issue above seems weird and the code snippet a bit hacky.

When I closed the music playback service from the notification bar, I called the following code to force close my app：
@Override
public void onDestroy() {
super.onDestroy();
.........
android.os.Process.killProcess(android.os.Process.myPid());
System.exit(0);
}
I got this problem when I restarted the app

This looks like an hack.


How to publish views to publish folder.

Could you please also extend this documentation about how to include views to publish folder?
<PropertyGroup>
<CopyRazorGenerateFilesToPublishDirectory>true</CopyRazorGenerateFilesToPublishDirectory>
</PropertyGroup>

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

ID: 8a83deb2-e035-bb66-be4f-68709bcad341
Version Independent ID: 16438f35-f35d-c097-0903-ec17e83e051e
Content: Razor file compilation in ASP.NET Core
Content Source: aspnetcore/mvc/views/view-compilation.md
Product: aspnet-core
Technology: aspnetcore-mvc
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

@pranavkm can you please try to provide content for this (should be very little).

The first link in this document points to the Razor SDK page, which documents the CopyRazorGenerateFilesToPublishDirectory property:

Razor files with a .cshtml extension are compiled at both build and publish time using the Razor SDK.

Given this, is there anything else we need to do here? Should we change the verbage to make it more obvious that the Razor SDK can be used to configure the build/publish steps?
@mkArtakMSFT @guardrex

It seems fine ... and there's a link directly to the content in the Additional resources section ...

* [RazorCompileOnBuild and RazorCompileOnPublish](https://learn.microsoft.com/en-us/aspnet/core/razor-pages/sdk?view=aspnetcore-6.0#properties) properties

@Rick-Anderson, please re-open if it needs more work.


Create middleware

#13

As I said here https://github.com/concretesolutions/redux-zero/issues/13#issuecomment-343637643 I think it's not possible to make a redux middleware work with redux-zero.
Maybe redux-zero can have your own middleware system, but I can not think of a practical application, since actions are pure functions.

Thanks for this @renatorib
What you think, @axetroy, @DarryID ?

@matheusml This looks very good for me can we try to make middleware  to handle API calls?

What you mean by that @Kiho?
Could you describe it with more details?

I will create a sample project in couple of days. I am think about to convert async actions to middleware.

Hi @matheusml I create sample project here https://github.com/Kiho/redux-zero/blob/middleware/examples/svelte/middleware/src/middleware/promise-middleware.ts to handle CRUD operation with @renatorib 's redux-zero middleware implementation.
It's not done and my method detection is not great but I think it's enough to show what it is.
Please check it out and let me know what do you think.

Hi @Kiho
Thanks for sending this.
So, @malbernaz improved the way we handle async actions a few days. Please take a look.
With that said, comparing to this solutions with middlewares, in my opinion, I really prefer @malbernaz's version.

Hi @matheusml,
I am not suggesting to replace  @malbernaz 's async action, just suggest you to ask  @renatorib to PR his mddileware system to redux-zero to give more flexiblity to consumers https://gist.github.com/renatorib/7364524579f5dbbc302030c9d1a3e7fb
This is the only part need to be added in redux-zero core is  https://github.com/Kiho/redux-zero/commit/25b8c731405394f76cb2470b4b4472efcca2b018
my middleware code is just simple sample usage of this system and you don't need to include it in the project.
I understand async action has more granular control on flow but middleware has some advantages like no code duplication, single line of code per action, and better maintainability.

@matheusml, I removed all hard coding here https://github.com/Kiho/redux-zero/blob/middleware/examples/svelte/middleware/src/middleware/promise-middleware.ts

Ok, @Kiho I agree with you.
@renatorib could you please add this to the project?

Hi @renatorib Please supply name as parameter return middleware(store)(newAction, name)

Maybe I did not get it right, but, what's this name?

Hi @renatorib, I can use name to filler actions in middleware, my code was very messy without it.
https://github.com/Kiho/redux-zero/blob/middleware/src/utils/bindActions.ts#L8
https://github.com/Kiho/redux-zero/blob/middleware/examples/svelte/middleware/src/middleware/logger-middleware.ts#L1
https://github.com/Kiho/redux-zero/blob/middleware/examples/svelte/middleware/src/middleware/promise-middleware.ts#L9

Hi @matheusml
Throwing in another possible middleware implementation for consideration.
The method signature and application was referenced from original redux middleware.
I haven't gone too much into the tests and docs yet, just wanted to throw this out and get feedback before going too much into it.
https://github.com/concretesolutions/redux-zero/compare/master...yeojz:feature/middleware

Hi @Kiho
I honestly do not like to pass the "name" of the action next to the middleware. It's name is not referenced to action itself (because it's just a pure function), but it's the bounded name, referenced in mapToProps. It could cause a bunch of conflicts and bugs difficult to identify, because I can bound in my whole application various actions and certainly some may have the same name. It becomes unpredictable, conflicting and insecure

Hi @renatorib
Maybe you are right. I understand possible naming collision and there is no guard for that.
But some use case like code sample above, I like to execute action selectively.
If you have any other way to accomplish that then I would be happy.

I made little bit safer version. https://github.com/Kiho/redux-zero/blob/middleware/examples/svelte/middleware/src/middleware/promise-middleware.ts

@renatorib and @Kiho
what you think about @yeojz's version? I think it's really promising

Hi @matheusml
I don't have time to test actual code now but  @yeojz's code looks very nice, specially middleware is totally pluggerable no code added to core other than place holders.

Exactly @Kiho
What about you @renatorib, do you have something to add?

@yeojz could you please open a PR with this?


Play -> Custom Games game tooltip to large

We know abut that issue apparently it is pretty hard to fix :(

So now we have a tracking issue :smile: .

I've just searched the issues and now I got what you mean. It seems my issue is a duplicate of #625 "Malformed tooltips of Game Tiles", just with a helpful screenshot :smile:. Shall we merge them?

They are automaticly merged by you commenting  #625 ;) no?

The tooltip always makes space for exactly twice the amount of teamcards that are shown.

Fixed


Summarize inherited parameters

I think this will really help make a codebase explorable, letting users focus on what's defined in each class while still being able to access all of the information. Thanks!


[Docs] Unclear how to use exclude-package-data

Summary
The docs explain that the exclude-package-data config is a table, but has no notes or explanation of how to use the field.  I would've assumed it would be an array of glob patterns to exclude, so I don't know what keys/values of this table should be.
OS / Environment
No response
Additional Information
This is a bit of an XY issue, where Y is "I don't understand the documentation for this option" and X is "I'm struggling to exclude _version.py, pkg/tests/*, and pkg/data/.gitignore.  Since it seemed automatic package discovery included these files, I'm trying to follow the instructions for Custom discovery
Code of Conduct

[X] I agree to follow the PSF Code of Conduct

Hi @Jacob-Stevens-Haas you can findmkre information about his conifg in https://setuptools.pypa.io/en/latest/userguide/datafiles.html

Alas, it's that simple.  I found that page and somehow missed the connection when it came time to use exclude-package-data.


Adjacent area wall collision

Door collisions in adjacent areas correct too far into the area

Improved behaviour by applying the entity correction when checking if the players current area needs to update


Revamp documentation

Create the following documentation pages:

getting started: intro
getting started: installation
getting started: rename basic usage -> quickstart, add a bit on hyperparameters
advanced usage: basic concepts
advanced usage: hyperparameters
advanced usage: tuners -> extend this in depth
advanced usage: selectors -> extend this in depth

Reorganize tree, see MLBlocks.
See also: https://hdi-project.github.io/MLBlocks/
See also: #52

Hey, I was searching through the documentation and I was wondering if there is direct support for MLBlocks Pipelines?
As in, give BTB a json with the MLBlocks Pipeline and start tuning. (I didn't find anything on it on the docs)

There is support for this, though you have to write a bit of glue code.
Basically, you load a mlblocks.MLPipeline from the JSON, create BTB tunable using Tunable.from_dict, and then pass the tunable to a BTBSession.
Full working example at https://github.com/ballet/predict-life-outcomes/blob/master/src/fragile_families/analysis/search.py#L168 - see lines 161-171
If you find this example works for your use case, please consider refactoring it into a general-purpose code snippet and making a PR to update the BTB docs!

@micahjsmith Thanks! I found a similar solution, though the one you presented does look a bit cleaner. I'll look into updating mine on the next couple of days. Thanks for the help!


message_id bind as 0

While binding the update body, message_id is set to 0. Allways

did you configure your webapp according to https://telegrambots.github.io/book/3/updates/webhook.html ?

I have the same issue, and it seems that [JsonPropertyName("message_id")]  is missing from the MessageId property, causing deserialization problems.

did you configure your webapp according to https://telegrambots.github.io/book/3/updates/webhook.html ?

Here is how I get the POST request:

All other values are correct except for MessageId

did you configure your webapp according to https://telegrambots.github.io/book/3/updates/webhook.html ?

Yes

Which version of the library are you using ?

Latest stable 19.0.0

Documentation is for stable versions v21.* (not available on Nuget)
You need to upgrade. See https://telegrambots.github.io/book/index.html#-installation for more info

did you configure your webapp according to https://telegrambots.github.io/book/3/updates/webhook.html ?

has you tried the example code?

I have the same issue, and it seems that [JsonPropertyName("message_id")] is missing from the MessageId property, causing deserialization problems.

good catch!


Build failed due to s3 dependency

Issue Summary
When I install the latest version of sqlite3 (5.1.4), I get the following error message when I try to run my code:
build failed (node_modules/@mapbox/node-pre-gyp/lib/util/s3_setup.js:43:28     const AWSMock = require('mock-aws-s3');): Could not resolve "mock-aws-s3"

It appears to pass this stage at 5.0.2, fails on 5.0.3
Steps to Reproduce

Start a raycast project
Install sqlite3 with npm i sqlite3
Use sqlite3 somewhere in your imports
npm run dev

Version
5.1.4
Node.js Version
v19.2.0
How did you install the library?
macOS Ventura, m1 (arm)

Do you have anything else odd going on with your setup? That bit of code should only be run of process.env.node_pre_gyp_mock_s3 is truthy

same to you.

Closing as there was no response.
It might be the case you need to ignore the dependency, but it's a devDependency only used for developing this package.

Sorry I took so long to get back to you, I'm guessing raycast does a webpack thing, will debug and reopen if there's something to do here

I'm seeing this as well. Installed in a standard cdk project and getting two errors:
✘ [ERROR] Could not resolve "mock-aws-s3"

    node_modules/@mapbox/node-pre-gyp/lib/util/s3_setup.js:43:28:
      43 │     const AWSMock = require('mock-aws-s3');
         ╵                             ~~~~~~~~~~~~~

  You can mark the path "mock-aws-s3" as external to exclude it from the bundle,
  which will remove this error. You can also surround this "require" call with a
  try/catch block to handle this failure at run-time instead of bundle-time.

✘ [ERROR] Could not resolve "nock"

    node_modules/@mapbox/node-pre-gyp/lib/util/s3_setup.js:112:23:
      112 │   const nock = require('nock');
          ╵                        ~~~~~~

  You can mark the path "nock" as external to exclude it from the bundle, which
  will remove this error. You can also surround this "require" call with a
  try/catch block to handle this failure at run-time instead of bundle-time.


Fixing CodeCov + CI only for PRs

Fixed a couple of things in the README, changed CI to be run only for PRs, no longer pushs, and fix the uploading of the CodeCov results.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@315084b). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #119   +/-   ##
=======================================
  Coverage        ?   33.41%
=======================================
  Files           ?       14
  Lines           ?     1598
  Branches        ?        0
=======================================
  Hits            ?      534
  Misses          ?     1064
  Partials        ?        0


Service data

When using the UI to configure an action, the default keyword used for data sent to the service is "data". It seems it should be "service_data"
I've had to update it myself in the code to have this working

Fixed in 0.3.1 and onwards.


Suppress automatic output in Jupyter notebooks

Fixes #44.

Will close this in favor of using a semicolon ; instead. Documented in #37 via commit c823076. Otherwise, overwriting the __repr__ method is a bit hacky.

Will close this in favor of using a semicolon ; instead. Documented in #37 via commit c823076. Otherwise, overwriting the __repr__ method is a bit hacky.