I'd love to help with Mac 800k

Avid collector of all things old-Mac here. Also an amateur digital archivist, which is how I stumbled across FluxEngine (your Reddit marketing (tm) worked).
I've ordered the board and got it all assembled, and have successfully imaged a couple of PC disks (getting 869 kB/s on the bandwidth-side so I'm living dangerously!). But what I'm really after is better support for 800k Mac images, both read and (in an ideal world) write.
I have setup a Macintosh Classic II which can read/write both 1.44MB "standard PC" and 800k (definetely not standard) disks. And 400k single-sided too. I also have a USB floppy drive and an iBook G4, allowing me to transfer files to the Macintosh Classic II. And, of course, I have a FluxEngine, allowing me to image disks.
So, basically, my question is: how can I help? I'm happy to image disks, test disks, etc...* if it will potentially lead to better support for these old Mac disks - as many as you like, for as long as you like**. I'd love to see a time where FluxEngine is able to both read and write 800k Mac images that are also compatible with the various emulators such as Mini vMac and SheepShaver (both of which I also have setup and available for testing).
*One thing that, right now, is more difficult for me to do is to take an 800k disk image and write it onto a disk. This is because Disk Copy (disk image writing program on older Macs) is very picky about what sort of disk images it handles, usually limiting it to ones it created that have the correct resource fork data (don't get me started). So while I can easily copy files onto 800k disks, making 800k disks on the Macintosh Classic II is difficult right now. Having said that, if that's what you need, then I'll try and work out some way of doing it!
**Subject to the hardware playing nicely! I went through several 800k disks before I found one that formatted successfully, and the Classic II plays up sometimes. But hey, that's part of the fun!

That's awesome! Glad to have your help.
FluxEngine does already technically support Mac 800kB disks (and probably 400kB ones too), but I've only successfully tested it on KryoFlux streams sent to me by someone else. I do have a few 800kB disks that were posted to me by someone but for some unknown reason they don't image properly. I don't know yet whether it's a problem with the disks or something at my end. I have suspicions that certain types of disks don't image properly. I've just received a logic analyser to investigate this but haven't done it yet. So if you could just try to read some disks and see what happens...
Write support needs some work; it's currently very much bodged together for the Brother and needs some proper refactoring. That's one of the next things to do.
The other thing which I don't know is how to produce or consume useful disk images. Mac disks are awkward as the tracks are all different sizes. What formats do Mini vMac and SheepShaver support?

OK! I've imaged some stuff that should provide a starting point. All of these images are taken using the same 800k disk, which was erased each time using the "Erase" option in System 7.1.
There are three groupings of files:

"blank": an image of a disk taken immediately after doing the "Erase" option in System 7.1. Note that it is not truly blank, and does contain a folder called "Desktop Folder" which System 7.1 hides.
"minisystem": a bootable System 6 disk image. Very minimal, containing only what is needed to boot. I've checked on my Macintosh Plus and this software on the disk I imaged does boot it.
"textfile": an erased disk with a single text file containing the string "this is a test". The name of the text file is "fluxengine"

So, as for the actual files I've attached: each "grouping" described above consists of three files:

A ".img" file. This is created using "sudo ./fluxengine mac", then subsequently renaming the file to match the name of the grouping.
A ".image" file. This is created on the Macintosh Classic II using the "Disk Copy 4.2" software.
A ".log" file. This is the final summary that FluxEngine prints after creating the ".img" file.

I've tested the ".image" files (the ones made by Disk Copy 4.2) and they all work in both the Mini vMac and SheepShaver emulators. Sadly none of the images made by FluxEngine work in the emulators.
From looking at the output summary by FluxEngine, I think it is apparent that the 800k disk I'm using is not in the best of shape, with quite a lot of errors. That being said, System 7 formats it fine (and refuses to format many of my other 800k disks, so it is a bit choosy), and when loaded up with the Minisystem it works fine as a System Disk. It's probably a typical example of a fairly-well looked after Mac disk!
Let me know if there's anything else I can do! Now for the files (I had to use a zip as GitHub didn't like the images files).

Thanks for those; that does sound like the behaviour I'm seeing with my disks, which suggests that there is a problem with the imaging. Curses. Although the pattern of errors in the log files looks kinda weird.
Can you run the fluxengine read mac stage with --write-flux=something.flux? Given the error rate you probably also want --retries=0 to prevent the drive from spending all of its time grinding. The --write-flux option will generate files containing the raw magnetic flux data, which can be decoded again without needing access to the physical disk. If you can send me those I can try to decode them.

OK! (Sorry for the delay, sleep then work took up my time!). Attached is a new zip, files2.zip, containing the exact same groupings (minisystem, blank and textfile) as last time, and a new .flux file for each of the groupings. Note that the other files are not identical to the files sent yesterday: although the same in purpose, I've recreated them all today to ensure an equal test.
And thanks for the tip of --retries=0. Not only did it stop all the grinding noises, it cut the time by about 2/3.
Let me know how else I can help!
files2.zip

There is something wrong with the sampler and it's dropping pulses. See #75. I'm investigating.

It's not a bandwidth issue on my end, is it? Two days ago I was fairly close to the 850 kB/s limit, and I didn't bother checking again yesterday (although I may have had a USB memory stick plugged in as well).
That being said, I was able to make a perfectly working copy of an IBM 1.44MB disk yesterday as well, so I don't think the bandwidth I was getting was too bad. Any idea how much 800kB Mac disks need?

No, if it were bandwidth you'd get a hard error and the read would stop. This is something altogether more subtle. I have no idea why it doesn't show up on IBM disks --- it's extremely weird.

When I get back tonight I'll try formatting the disk as 400kB single-sided and seeing if there is any difference. (Unfortunately I don't think I have a brand new, unused DD disk to try).
Is it worth me trying to generate a flux image using another software decoder (ie: "ibm" rather than "mac") or is the flux code shared between all the software decoders?

The flux images should all be the same; the only difference is that the decoder is used to check whether the image was read correctly (floppy disks suffer from perfectly normal transient errors, which need to be retried, but you need to know the data encoding in order to check for these).
IIRC the 400kB format is just the same as the 800kB one but just uses one side, so I don't think there'll be any difference there.

So, er, turns out that the sampling error could well have been fixed for a while now. You just need an extra command line parameter.
$ ./fluxengine read mac -s /tmp/tosend2/blank.flux:s=0 --bit-error-threshold=0.3
H.SS Tracks --->
0. 0 ...........................................................B....................
0. 1 ................................................................................
0. 2 .....................B..........................................................
0. 3 .............................................................B..................
0. 4 ......................B.........................................................
0. 5 ................................................................................
0. 6 ................................................................................
0. 7 ................................................................................
0. 8 ..............................B.................................XXXXXXXXXXXXXXXX
0. 9 ................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.10 ................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.11 ................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Good sectors: 795/960 (82%)
Missing sectors: 160/960 (16%)
Bad sectors: 5/960 (0%)
80 tracks, 1 heads, 12 sectors, 524 bytes per sector, 491 kB total

The Bs represent bad sectors, which will probably go away on real hardware if you let it retry failed reads; the Xs represent sectors which aren't present, which is perfectly normal on Mac disks because the inside has fewer sectors than the outside.
Could you give that a try and let me know if it works? You may want to update from git (and rebuild and reprogram the firmware) first. Thanks!

OK, updated from git and reprogrammed the PSoC. Unfortunately it still didn't work. The exact command I ran was sudo ./fluxengine read mac --bit-error-threshold=0.3. I see in the example command you gave about you had ":s=0", which I presume means only do the first side. For you, this created a disk image 491kB in size, which is about right. However I didn't do the ":s=0", and yet I still got a disk image 491kB in size. Perhaps this is the reason it didn't work? I only did "textfile" and "blank" this time, and didn't make Disk Copy images (can do easily, just wanted to save time to let you know about this ASAP).
After writing the above I realised I had forgotten to recompile the tool after updating from git. So I did that, but it still didn't work. Also, the output is now.... weird. See the 'afterupdate.log' and 'afterupdate.img'. This is of the "blank" disk.
files3.zip

What it's done is that it's read both sides, but it's found sectors on side 1 which claim they're from side 0, which is a conflict. These are the C sectors in the map. FluxEngine always trusts the sector header to get the sector ID rather than the physical location (which is sometimes wrong).
The weirdness is because there's a bit error in a sector header on side 1 so it's claiming to be sector 255. I've put in a sanity check for this as it's clearly wrong. (In git branch 'mac'.)
A bit more investigation with my new tools has revealed the multiple reads of a Mac disk are definitely losing pulses. I've reopened #75 (more info there)...

I'm still thinking about this!
The good news is that I've rewritten most of the reading and writing firmware, and it's producing much better results than before. My disks are still not great but the difference is astounding. Given that your disks were mostly generating better results, I'd be interested to know if this helps you at all if you're interested in giving it a try.
You'll need to rebuild the client and reinstall the firmware.
Thanks!

Terribly sorry for not responding sooner - end-of-year uni exams followed by Christmas limited my free time.
I've re-flashed the new firmware and rebuilt the software, but frustratingly I'm getting the Error: cannot find the FluxEngine (is it plugged in?) message when I try fluxengine rpm.
I've done the usual, trying different USB cables, checking that ninja-build, libusb-1.0-0-dev and libsqlite3-dev are all installed. I've also re-flashed the old firmware to see if that made a difference (it doesn't). Frustratingly I didn't check to see if everything still worked before I rebuilt the client / flashed the updated firmware. I've also verified that lsusb detects the board as Bus 001 Device 010: ID 1209:6e00 Generic, which matches the PID / VID in protocol.h.
I don't want to turn this issue into teh n00b can't do USB so I'm happy to open a new issue if that would make troubleshooting easier.
It is possible I screwed things up. I don't know why it would be showing up with the right USB ID but still uncontactable, though. Do you need sudo to give the client access to USB? I have one machine where I do and one where I don't and I keep getting it wrong.
If that's not it, then I'd suggest forgetting about it until January and I get home to my hardware. Currently I'm about 1500km away from it...

@davidgiven Is your user perhaps in the dialout group on one machine and not the other? This is a common cause of this kind of issue for serial connections under Linux.
Also, status on this?

On my side, the status is Eek, I'd completely forgotten about this.
I cannot honestly remember where I got last with this - so I'll assume nothing and re-flash the latest firmware / use the latest software before trying to image some disks.

Yeah, I, uh, got busy with other things. (I wrote a compiler! http://cowlark.com/cowgol)
At my end: someone contributed some drastically bugfixed sampler code, which is giving me much cleaner Mac disk reads on my hardware. Also, someone else contributed a semi-improved decoder. When this works, it works very well, but it also frequently makes things worse. I'm still working on that one and it's not merged.
If you want to try imaging some disks, that'd be awesome, but I don't need the whole set --- I know it takes forever.

Nothing about the dialout group? Damn.
Also that is a perfectly acceptable use of time! I might actually DM you... somewhere? about this.

So after a slight .... delay when I couldn't get the Mac to boot (I really need to replace the capacitors on the logic board!), I have made an image of the disk. The disk used is a blank 800k disk (freshly formatted in the mac).
The command I used was fluxengine read mac --bit-error-threshold=0.3. I've attached both the resulting disk image and the log produced, in a zip file (since GitHub doesn't like disk image files). (I check to make sure the setup was working correctly by imaging a regular IBM disk, which worked fine).
The output was a 490kB disk image... which is around half the size I would expect for an 800k disk. On the positive side of things, there was only a very small number of bad sectors (18 out of 960) and the 490kB disk image compresses very well in the zip, which I would expect for a blank disk.
I did try the disk image in the Mini vMac emulator, and it wasn't recognised, so evidently there are still some issues.
As before, I'm happy to do whatever imaging combinations are needed to help you debug this!
mac-read.zip

Would the flux reading not be more useful?

@Icekhaos That's a very good point. I can certainly do so.
@davidgiven what would you prefer? (And any specific command-line options I should pass?)

Actually, it's the log that's the really useful bit.
What I see is that the sectors on side 0 have the same IDs as the sectors on side 1, but other than that it's a completely clean read. This could mean it's a 400kB disk, or it could mean that I'm wrong about where the side bit is stored (see decode_size() in arch/macintosh/decoder.cc). I'm thinking it's more the latter. The conflicting sectors are because FluxEngine can see two copies of the same sector which are different (the ones on each side). The rest of the sectors won't conflict because the two sides store the same data --- the most likely explanation is that they're empty.
I think I may have a disk here which exploits the same symptoms... I'd always thought it was a 400kB disk. Let me get back to you on that one.

Whoops, I fixed this but attached the message to the wrong bug... turns out I was testing the wrong bit in the side byte, which is highly embarrassing. Current head of git should have a fix for it (no firmware upgrade needed). Judging by the rest of your log, I think that should give you clean reads.

Aha, running with the new client does produce disk images of a much more sensible size - 982kB. (And like before, the disk image compresses very well (down to 2.1kB), suggesting the blank disk is being read successfully.
Unfortunately, the disk isn't being recognised by either the Mini vMac or SheepShaver emulators (they recognise it as a disk image, but not as a Macintosh-formatted disk). I'm guessing this is where things get a bit more complicated, with checking of disk image specs, and a "spot the difference" between "genuine" Mac images and the ones the FluxEngine produces.... I admit I'm completely out of my depth when it comes to these sorts of things, but I can pass along the following links describing how the Mini vMac emulator deals with disk images:
How to work with Disk Images
Emulated Hardware - Floppy Drives
In particular, the following passage in the second link caught my attention:

The preferred disk image format for Mini vMac is a file containing just the image data, with no header, trailer, or resource fork (and therefore without checksums or tag data). Mini vMac will accept disk images in formats with trailing information and no header, except that it will pass an incorrect disk size to the emulated computer, which affects programs such as Disk First Aid.

Oh, and here's the output from the latest read:
mac.zip

Good news. The next stage is to emit disk images which emulators can understand. I'm not at all surprised the existing ones don't work --- the triangular disk image shapes are a pain.
There's actually an open bug to support DiskCopy 4.2 images (#85), and it looks like vmac supports these according to the link, so I'll take a look at those.

I have a flux file of an 800k floppy with an attendant .img file produced by another flux imager. Linux is able to mount this .img file, but not the one FluxEngine produces.
I suspect the format is simply each track in order, each sector up to the liimit that can be put on the disk (no spacing for invalid sectors), all without metadata. But I'll send you the image by mail so you can take a look.
While I'm reasonably sure there's very little private data on the disk, it's from a computer that's not strictly speaking mine, so I don't feel like I should put it up here in public.

Seemingly GitHub doesn't send email alerts when PRs are mentioned in an issue, so I didn't realise that you'd patched this until today.
I've now imaged several Mac disks successfully, and they work great in the various emulators that I have (Mini vMac and SheepShaver). Thanks so much for spending the time to get this to work - it'll be a game changer as I no longer need to rely on old hardware to image disks!
A couple of thoughts on potential extensions (no doubt "possible extensions" is the last thing you want to hear):

It would be nice to support the "raw" image format that the emulators use, as unless compiled with the options enabled, Mini vMac (and I believe SheepShaver as well) cannot write to DiskCopy images (quite sensibly, it's a storage / preservation format, rather than a in-use-disk format). I'm wondering if it would be as simple as stripping off the DiskCopy headers/footers to expose the raw disk image? (For comparison I can create an 800k 'raw' disk image that works in Mini vMac using hfsutils on Linux using the commands dd if=/dev/zero of=disk.raw bs=1k count=800 && hformat disk.raw ).
What do you think the chances are of ever having write support for Mac disks in FluxEngine? Being able to read and write mac disks would be unbelievably cool (many folks in the Vintage Mac community have a "later-era" Mac used solely for transferring files from 1.44MB IBM formatted disks to the 400k / 800k disks required by earlier Macs - if FluxEngine could write to disks these separate Macs would no longer be necessary).

A huge thanks again for adding support for Mac disks, and all the time and effort it's taken to do this. Feel free to close this issue now and work on the above ideas later (or never - no obligations!). I'm always happy to try out things needing "real" Mac hardware, if you ever need it.
Thanks again!

Fantastic --- I'm glad that is working for you!
Regarding raw disk formats: Mac disks are weird. There's that extra 12 bytes of metadata per sector, which has to go somewhere. DiskCopy files put all the normal data first, and then there's a chunk at the end of the file for the metadata, so by stripping off the header you effectively just get the 512-byte sector data. I believe that's what you get with dd too. I know that some applications need it and some don't, but don't know the details...
Regarding writing: yes, that's perfectly possible. However I'd need some hardware to test on to make sure the disks are readable. I'm actually hunting for an old Mac of some description but they're not cheap.

If it's a help, the dc2dsk command line tool can convert from DiskCopy images to raw images. (It was written for use with the Floppy Emu floppy drive emulator, since although the Floppy Emu can read DiskCopy images, it cannot write to them - much like Mini vMac and SheepShaver).
The source for dc2dsk is 3-clause BSD (and is only 122 lines, 72 with the license and comments stripped), but I completely understand if you don't want to start including BSD code in the MIT-licensed FluxEngine. In that case, might I suggest a link to dc2dsk in the docs for reading Mac disks?

I've just merged a change which adds write support for Mac 800kB floppies --- it works fine given the extensive testing I did (I tried it a couple of times on a PowerBook 150). I can download a bootable DiskCopy System 6 floppy from archive.org and then boot from it, at least up until the point where it hangs because the 150 doesn't support System 6. It's also got read and write DiskCopy 4.2 file support.

I've just merged a change which adds write support for Mac 800kB floppies --- it works fine given the extensive testing I did (I tried it a couple of times on a PowerBook 150). I can download a bootable DiskCopy System 6 floppy from archive.org and then boot from it, at least up until the point where it hangs because the 150 doesn't support System 6. It's also got read and write DiskCopy 4.2 file support.

Wow! This is incredible! I've only played around with it for an hour or so, but it seems to be working seamlessly. I've written back some disks I'd made images of using FluxEngine, and they work great.
This is going to be a real game changer for how I deal with getting software to/from my Macintosh Plus. I'm so unbelievably grateful to you for getting this working - thank you!!!
Now that this is working reliably, it would be interesting to see how dependent it is on the floppy drive used. When I have time, I'll try and go through my box of floppy drives, documenting which ones work and which ones have issues. (As a single data point, the drive I randomly grabbed from the pile is a Mitsumi D359T5).

Wow! This is incredible! I've only played around with it for an hour or so, but it seems to be working seamlessly. I've written back some disks I'd made images of using FluxEngine, and they work great.
This is going to be a real game changer for how I deal with getting software to/from my Macintosh Plus. I'm so unbelievably grateful to you for getting this working - thank you!!!
Now that this is working reliably, it would be interesting to see how dependent it is on the floppy drive used. When I have time, I'll try and go through my box of floppy drives, documenting which ones work and which ones have issues. (As a single data point, the drive I randomly grabbed from the pile is a Mitsumi D359T5).

Excellent --- I'm glad that works! (Also, booting of a CLV disk plays all sorts of interesting tunes on the floppy drive as it speeds up and slows down.) It was actually much easier to write the encoder than the decoder; I should have done it way sooner.
I'm still searching for a surface scanner for MacOS, BTW. FluxEngine doesn't do any kind of verification. It does seem capable of reading its own disks, but checking this on the Mac would be a good idea.

Excellent --- I'm glad that works! (Also, booting of a CLV disk plays all sorts of interesting tunes on the floppy drive as it speeds up and slows down.) It was actually much easier to write the encoder than the decoder; I should have done it way sooner.
I'm still searching for a surface scanner for MacOS, BTW. FluxEngine doesn't do any kind of verification. It does seem capable of reading its own disks, but checking this on the Mac would be a good idea.

BTW, I wrote a tool for actually measuring how well a given drive copes with non-PC-format pulse intervals. This should reveal problematic drives.
http://cowlark.com/fluxengine/doc/driveresponse.html

BTW, I wrote a tool for actually measuring how well a given drive copes with non-PC-format pulse intervals. This should reveal problematic drives.
http://cowlark.com/fluxengine/doc/driveresponse.html

for analysis reference, here's a sony drive scp that verifies correctly
sonymac800.zip

here's one with 3 revolutions and bad high sectors
badsectors.zip


Version correlation

I'm trying to find a relationship between the version number of the versions.json file with the x.x.x patch notation
This exists ?
How do you identify which version X of a game is the latest ?
For example in Legend of Zelda breath...
"01007ef00011e000": {
"393216": "2017-08-14",
"524288": "2017-11-08",
"589824": "2017-11-21",
"655360": "2017-12-08",
"720896": "2018-01-31",
"786432": "2019-04-25"
},
"524288": "1.3.3",
"589824": "1.3.4",
"655360": "1.4.0",
"720896": "1.5.0",
"786432": "1.6.0"

This would be the relationship according to the dates on the official website of the game

Thank you so much !!!

Look at the meta info in the patch file (assuming you have it)

I don't have any files related to the games.
It is only the list of games available with their dlcs and versions, in a format that people understand as they appear on some official pages with the number 1.xx.xx and not as 654464

Unfortunately they do not


"How can I help?" README update

This PR adds a "How can I help?" section to the README so people have a more clear path to getting started.

[Current coverage][cc-pull] is 85.55%

No coverage report found for master at d856e7c.

Powered by Codecov. Last updated by [d856e7c...7cbe983][cc-compare]
[cc-base-branch]: https://codecov.io/gh/TechnologyAdvice/stardust/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/TechnologyAdvice/stardust/compare/d856e7c3d78c3e09147ad8c46619a65a768cd60e...7cbe983b3563af1bbd16925fecf57334c522a0ad
[cc-pull]: https://codecov.io/gh/TechnologyAdvice/stardust/pull/270?src=pr

🌴

👻


Preserve null fields

Currently the table header is taken from the first result when processing streaming expressions. Also each subsequent tuple is assumed to have each field the first tuple has. This causes all kinds of display problems when either the first tuple or subsequent tuples don't contain all fields in the result set.
In general this doesn't cause issues with aggregations or statistical visualizations because these result sets have very consistent field structure across the result set. But it reeks havoc with exploratory searches viewed in tables.
This ticket does a very thorough job of creating the header by looping through each tuple to create the unique set of fields. It also ensures that nulls are preserved in all tuples with tabs.

As a nice added bonus this ticket also simplifies the output for different types by simply calling toString on each tuple value. This means arrays are now bracketed in the Zeppelin table viz.

All unit tests pass so I plan to merge to master shortly. I'll do more testing from master before a release.


A few renaming suggestions

What if we renamed cupid-dev -> cupid-infrastructure? Then we can talk about differentiating between the infrastructure to run CUPiD and the analysis done by CUPiD (non-developers still need to install this environment to use CUPiD)
What if we renamed cupid-build -> cupid-publish? I'm trying to think of a better verb for creating a website, since build is often associated with compiling code. Or we could add a --make-html flag to cupid-run and get rid of cupid-build altogether. It's not clear to me that we really need separate commands; if you run cupid-run and then realize you want HTML output, cupid-run --make-html will notice that the notebooks are up-to-date and won't try to re-run them.

I agree that the cupid-dev naming should be reconsidered. I think cupid-infrastructure could be a good option. I'm also wondering if something to specify that this is the environment which you run from, or even also calling the environment cupid-run could be helpful? Although we do also run cupid-build from that environment, too.
If we added a --make-html flag, I'm wondering how we would know that the notebooks are up-to-date? Eg, would we log the configuration information along with running cupid?

Maybe cupid-executables for the environment? Although I could see cupid-run being the right choice for the environment if we only provided a single executable for all functions (maybe we'd call that executable cupid without any hyphenated modifier?)
For --make-html, I was just thinking that if you run cupid-run twice in a row the second execution would be much faster because it would realize the notebooks are already up-to-date... I'm not actually sure how that happens (maybe something in ploomber), I've just noticed it when I've run through examples.

I do think cupid-run would be easier to type than cupid-executables, and I would support just calling the executable cupid.
Ah, right! And if we expect users to run the notebooks and then immediately run the 'build' bit, would it make more sense to have the default be to make html after notebooks are run, and have a flag option for --skip-html?

Perhaps slightly tangential but still relevant, in #118 Mike suggested that we "clean up the names of the directories cupid-run creates -- maybe CUPiD_out/ with computed_notebooks/, computed_scripts/ (once we finish https://github.com/NCAR/CUPiD/issues/93), and html/ (created by cupid-build rather than cupid-run)." We could make these modifications at the same time as the aforementioned renaming suggestions.


[Android] TextInput On Tablet not centrilized Text

This is My code
import React, { Component } from 'react';
import {
  AppRegistry,
  StyleSheet,
  Text,
  TextInput,
  Image,
  View
} from 'react-native';

class TestSizes extends Component {
  render() {
    return (
      <View style={styles.container}>
        <TextInput style={{backgroundColor: '#aaa'}}>
          TEST TEXT ON TEXTINPUT
        </TextInput>
      </View>
    );
  }
}

const styles = StyleSheet.create({
  container: {
    flex: 1,
    flexDirection: 'column'
  }
});

AppRegistry.registerComponent('TestSizes', () => TestSizes);

and what i see in screen.
https://s9.postimg.org/bw6wdn5lr/Screenshot_2016_08_09_20_53_37.png
It bug i see only on Tablet. In small device it ok! Text  is centrilized.

I don't think I follow what you mean by "centrilized"? Do you mean centered vertically in the text input? or something else?

@rmevans9  Yep) This is bug with auto padding in TextInput. this can be solved by using padding: 0 in textInput, but it not normal)Because this fine work on small device but not work pretty in bug device size like Tablet)

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/android-textinput-on-tablet-not-centrilized-text
ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub.
Also, if this issue is a bug, please consider sending a PR with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.

@facebook-github-bot label Icebox

@facebook-github-bot close


Use a value set on the state itself rather than an isReady flag

When redux initializes it passes a couple of actions to each reducer.
This initialization was setting the "isReady" flag. If we have an
initial state coming from outside of the reducer, however, then on the
actual @@INIT pass the isReady flag would be true and the state be
defined even though it isn't actually initialized.
By using a flag on the state itself we can ensure that the state is
properly initialized.
Fixes #16

Coverage remained the same at 84.615% when pulling e1d7c92e7e1793d29da2d50c113707eccfd323cc on clayne11:ssr into e443f0900ceaede36691d799efc6dfd12b048c86 on mattkrick:master.

awesome, thanks for the PR!
To make sure there are no regressions (and so I can more fully understand the problem) could you change the new test to be something that would fail under the current version? That way, changing how we achieve the goal shouldn't affect the desired result.

No problem - I added a test that fails on the master branch but passes on the branch with my fix.
I had to add redux as a devDependency to show the issue.

Coverage remained the same at 84.615% when pulling f4cb2f471dfa58e83c5b3ec92ded6031167f33dd on clayne11:ssr into e443f0900ceaede36691d799efc6dfd12b048c86 on mattkrick:master.

Coverage remained the same at 84.615% when pulling f4cb2f471dfa58e83c5b3ec92ded6031167f33dd on clayne11:ssr into e443f0900ceaede36691d799efc6dfd12b048c86 on mattkrick:master.

Coverage increased (+7.7%) to 92.308% when pulling 6fef62bd33f9ec7085a24bb162ebf869fea82099 on clayne11:ssr into e443f0900ceaede36691d799efc6dfd12b048c86 on mattkrick:master.

Coverage increased (+7.7%) to 92.308% when pulling 6fef62bd33f9ec7085a24bb162ebf869fea82099 on clayne11:ssr into e443f0900ceaede36691d799efc6dfd12b048c86 on mattkrick:master.

Ohhhh now I see what's up, thank you!
I'm still not in love with the implementation, because then we're keeping a 1-way flag in our state the whole time. This should be private state because it's a part of the implementation & has no useful info for the user. As is, this is required because we'd create a state, then override that state with the preloadedState, then override that preloadedState with an optimistic version of itself.
Instead, what if you just did this?
const dataToLoad = {counter: 0};
const preloadedState = Map({
  beforeState: undefined,
  history: List(),
  current: dataToLoad
});
const store = createStore(enhancedReducer, preloadedState);

I wouldn't be opposed to a helper function that did this for you, so we could write:
const store = createStore(enhancedReducer, preloadState({count: 0});

The issue for me is that I'm only using optimistic on a sub-reducer, not on the root reducer. It's not trivial to preload a specific nested reducer with without hardcoding a relationship between the instantiation of the store and specifically which reducer is optimistic.
I suppose I could preload the state the way you're suggesting, though. Neither solution seems ideal to me.

Agreed, it's not great.  Since your state tree is deterministic, it wouldn't be hard to write something like this:
const dehydratedState = {
  foo: 0,
  bar: {
    baz: 0
  }
};

const optimisticParts = ['foo', 'bar.baz'];

const optimistify = (dehydratedState, optimisticParts) => {
  optimisticParts.forEach(subState => {
    const depths = subState.split('.');
    depths.reduce((left, right, idx) => {
      if (idx < depths.length -1) {
        return left[right];
      } else {
        left[right] = preloadState(left[right]);
        return left[right];
      }
    }, dehydratedState)
  })
}

By declaratively scoping your optimistic parts, you make your code really easy to grok for future you, since the enhancer itself will probably get applied in your async router so you never really get the full picture.

Fair enough. I'll change the PR to be for a helper function to preload state.

Added a new PR https://github.com/mattkrick/redux-optimistic-ui/pull/18


Merge pull request #1 from RomelTorres/develop

Latest Pull

What is this doing?

Closing due to inactivity.


RTMP live issue with a Haivision Makito encoder

I experience issues with a Haivision Makito live encoder connecting to NGINX RTMP. Configurationwise everything seems alright, but the encoder is not able to connect.
Tested with NGINX 1.8.0 (latest stable) RTMP module current git repo. Also tested with nginx 1.7.10 plus latest repo.
Configuration:
worker_processes 4;
worker_rlimit_nofile 8192;

user www-data;
pid /var/run/nginx.pid;
error_log /var/log/nginx/error.log debug; # +" debug";

events {
  multi_accept on;
  worker_connections 1024;
}

http {
  include mime.types;
  include /etc/nginx/conf.d/*.http.conf;

  map_hash_bucket_size 128;
  default_type application/octet-stream;

  sendfile on;
  tcp_nopush on;
  keepalive_timeout 65;
  gzip off;

  ## Logs
  ...

  # Include site configuration files
  include /etc/nginx/sites-enabled/*;

} # http

# Multi worker streaming
rtmp_auto_push on;
rtmp_auto_push_reconnect 1s;
rtmp_socket_dir /tmp;

rtmp {

  server {

    listen <ip-address>:1935;
    listen localhost:1935;
    chunk_size 4096;
    notify_method get;

    # Max connections to RTMP engine
    max_connections 200;

    wait_video on;

    # Live test
    application live {
      live on;
      record off;
      allow publish <ip-address>;
      deny publish all;
      allow play all;
    }

} # server

} # rtmp

With other RTMP encoders, such as Wirecast I am able to connect with no issues.
For Haivision, debug log shows this:
2015/09/14 12:16:53 [info] 6492#0: *74 client connected '<IP_ADDRESS>'
2015/09/14 12:16:53 [info] 6492#0: *74 connect: app='live' args='' flashver='LNX 10,0,32,18' swf_url='' tc_url='rtmp://<snip>:1935/live' page_url='' acodecs=0 vcodecs=0 object_encoding=0, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
2015/09/14 12:16:54 [info] 6492#0: *74 createStream, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
2015/09/14 12:17:08 [info] 6492#0: *74 deleteStream, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
2015/09/14 12:17:08 [info] 6492#0: *74 disconnect, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
2015/09/14 12:17:08 [info] 6492#0: *74 deleteStream, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935 ...

I can see no publish() call here.
The same for Wirecast (as a working example):
2015/09/14 12:49:54 [info] 6492#0: *75 client connected '<IP_ADDRESS>'
2015/09/14 12:49:54 [info] 6492#0: *75 connect: app='live' args='' flashver='Wirecast/FM 1.0 (compatible; FM' swf_url='' tc_url='rtmp://<snip>:1935/live' page_url='' acodecs=1026 vcodecs=128 object_encoding=0, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
2015/09/14 12:49:54 [info] 6492#0: *75 createStream, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
2015/09/14 12:49:54 [info] 6492#0: *75 publish: name='222222' args='' type=LIVE silent=0, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
...

I made captures for both encoders:
https://dl.dropboxusercontent.com/u/28051694/nginx-rtmp_captures.zip
First a successful NetConnection.Connect.Success is achieved by both encoders. The difference is that Wirecast starts off with ReleaseStream(), FCPublish() and createStream() calls in a single RTMP packet. In contrast, Haivision starts with a createStream() then an FCPublish() follows in the next packet, then an FCUnPublish() occurs immediately.
Thanks.

Try worker_processes 1; first.

I have the same problem with the Makito X, logs below.  We ended up setting the Makito to MPEG-TS and using ffmpeg to publish via RTMP.
Makito X with no publish
2015/06/09 10:03:18 [info] 14577#0: *10 client connected '<IP_ADDRESS>'
2015/06/09 10:03:18 [info] 14577#0: *10 connect: app='myapp' args='' flashver='LNX 10,0,32,18' swf_url='' tc_url='rtmp
://XX.XX.XX.XX:1935/myapp' page_url='' acodecs=0 vcodecs=0 object_encoding=0, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
2015/06/09 10:03:19 [info] 14577#0: *10 createStream, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
2015/06/09 10:03:35 [info] 14577#0: *10 deleteStream, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935

ffmpeg with a publish
2015/06/09 09:39:21 [info] 14577#0: *6 client connected '<IP_ADDRESS>'
2015/06/09 09:39:21 [info] 14577#0: *6 connect: app='myapp' args='' flashver='FMLE/3.0 (compatible; Lavf56.25' swf_url
='' tc_url='rtmp://XX.XX.XX.XX:1935/myapp' page_url='' acodecs=0 vcodecs=0 object_encoding=0, client: <IP_ADDRESS>, ser
ver: <IP_ADDRESS>:1935
2015/06/09 09:39:21 [info] 14577#0: *6 createStream, client: <IP_ADDRESS>, server: <IP_ADDRESS>:1935
2015/06/09 09:39:21 [info] 14577#0: *6 publish: name='mystream' args='' type=live silent=0, client: <IP_ADDRESS>, serve
r: <IP_ADDRESS>:1935

It's because there is no FCPublish/FCUnpublish handlers.
Which usualy sends 'NetStream.Publish.Start' / 'NetStream.Unpublish.Success' response.
After that - encoders will send publish / unpublish commands.

Sergey. I gave it a try, does not work either. Same effect.
However, I tried with the product of the same company called Kulabyte, which has maybe more complete RTMP implementation, and it worked fine.
Sergey, can you tell me, that in this situation:

Haivision Makito does something wrong. If yes, I can try to have it fixed with the vendor.
NGINX lacks something. In this case, any chance to improve the module on the NGINX side?

Thank a lot.

Haivision just doing streaming with strict rules. Probably following some Adobe recomendations.
But FC(un)Publish commands not required for publishing - FMLE working without hanblers in nginx-rtmp.
If you want to try - in my fork I have created that handlers. You are not alone: https://github.com/sergey-dryabzhinsky/nginx-rtmp-module/issues/38

Sergey, great, thanks. I tried to compile it with Nginx 1.8.0, but it fails:
/home/akovacs/temp/nginx-1.8.0/nginx-rtmp-module-fcpublish//ngx_rtmp_send.c: In function ‘ngx_rtmp_create_fi’:
/home/akovacs/temp/nginx-1.8.0/nginx-rtmp-module-fcpublish//ngx_rtmp_send.c:932:5: error: pointer targets in passing argument 1 of ‘sprintf’ differ in signedness [-Werror=pointer-sign]
In file included from src/os/unix/ngx_linux_config.h:23:0,
                 from src/core/ngx_config.h:26,
                 from /home/akovacs/temp/nginx-1.8.0/nginx-rtmp-module-fcpublish//ngx_rtmp_send.c:8:
/usr/include/stdio.h:361:12: note: expected ‘char * __restrict__’ but argument is of type ‘u_char *’
/home/akovacs/temp/nginx-1.8.0/nginx-rtmp-module-fcpublish//ngx_rtmp_send.c:934:5: error: pointer targets in passing argument 1 of ‘sprintf’ differ in signedness [-Werror=pointer-sign]
In file included from src/os/unix/ngx_linux_config.h:23:0,
                 from src/core/ngx_config.h:26,
                 from /home/akovacs/temp/nginx-1.8.0/nginx-rtmp-module-fcpublish//ngx_rtmp_send.c:8:
/usr/include/stdio.h:361:12: note: expected ‘char * __restrict__’ but argument is of type ‘u_char *’
cc1: all warnings being treated as errors
make[1]: *** [objs/addon/nginx-rtmp-module-fcpublish/ngx_rtmp_send.o] Error 1
make[1]: Leaving directory `/home/akovacs/temp/nginx-1.8.0/nginx-1.8.0'
make: *** [build] Error 2

Sergey, your fix works as expected. Makito live streaming works out-of-the-box. Thank you very much.
Any chance that this fork will be part of the RTMP module mainline? Thanks indeed!

Yeah, I'll fix type conversion.
About my fork - don't know. @arut seems like not have much time for code review.

Thanks. I close the issue.

I have a docker image with this patch up at https://hub.docker.com/r/emersonian/nginx-rtmp-haivision which has been stable for over six months in a production environment with Haivision encoders.
Thank you again to @sergey-dryabzhinsky for this fix!


usb_dwc3: shutdown the DART as well when shutting down usb

Signed-off-by: Sven Peter<EMAIL_ADDRESS>

This one would be helpful for u-boot as it means the existing dwc3 driver just works.

linux as well once a small bugfix<EMAIL_ADDRESS>reaches upstream


Feed Issue: Objective-See

This has been a problem for some time, (not specifically NNW6) but whenever I add the Objective-See RSS feed, (macOS security software), all entries are retrieved with the same data/time; specifically the date and time I import the feed. This results in all the entries appearing in a somewhat random order.
I can't see anything obviously wrong with the feed itself: https://objective-see.com/rss.xml
It doesn't help the the two most recent entries have exactly the same published date, however the pubDates of the last couple of entries are:

Sun, 14 Feb 2021 00:00:00 EST
Sun, 14 Feb 2021 00:00:00 EST
Tue, 5 Jan 2021 00:00:00 EST
Fri, 1 Jan 2021 00:00:00 EST
Thu, 10 Dec 2020 00:00:00 EST

From NetNewsWire 6:

The feed xml:

If you go further down that feed you'll come across some entries that have no pubDate, e.g.
  <item>
    <title>Weaponizing a Lazarus Group Implant</title>
    <link>https://objective-see.com/blog/blog_0x54.html</link>
    <description>The Lazarus group's latest implant/loader supports in-memory loading of 2nd-stage payloads. In this post we describe exactly how to repurposing this 1st-stage loader to execute *our* custom 'fileless' payloads!</description>
    <guid isPermaLink="true">https://objective-see.com/blog/blog_0x54.html</guid>
  </item>

In these cases, NNW uses the date the article arrived in the app. That's why old articles appear new (or newer that actual new post). It's not so much an issue with NNW than it is an issue with the feed.

Ah, well spotted. I'll see if I can contact the feed owner. Thanks!


bundle_install doesn't respect application owner

bundle_install runs either as chef user or root. It should respect and run as the enclosing application owner.

A workaround is to specify the user in the bundle_install resource:
  bundle_install do
    user 'gitlab-contributors'
    deployment true
    without %w(development test)
  end


250 implement react query for input title updates

Description

Created API function for updating input title
Implemented data mutation for updating input title

Fixes #250
Type of change

[X] ✨  New feature (non-breaking change which adds functionality)

How Can this be tested? Testing Plan to review this PR

[X] Where in the app does this change take place?
UserInputList

[X] What are the steps to test this change?

Checklist:

[X] I have performed a self-review of my own code.
[X] I have commented on my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[X] My changes generate no new warnings.
[ ] Any dependent changes have been merged and published in downstream modules.
[X] I have reviewed the Security Best Practices Document.
[X] I have followed the Naming Conventions Guide for my changes.
[X] I have ensured that my pull request title is descriptive.

Additional Information:
Integration with UI and snack bar notification will be handled in #125.

@colinvandergraaf I think because the onSucess triggers a re-fetch of the inputHistory so the list gets re-rendered which causes the flickering. I will take a closer look to see how I can reduce the flickering.


chore(main): release 1.1.0

:robot: I have created a release beep boop
1.1.0 (2024-02-07)
Features

add new features (117ec7b)

Build System

add basalt logger (f5e50e2)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/Andesite-Lab/dealer-i18n/releases/tag/v1.1.0 :sunflower:


integrations: Remove box-shadow offset on search box.

It looked a bit odd, since We don't use box-shadow offsets anywhere else on
the page (or the app as a whole).

Merged, thanks @rishig!


Migration to Material 3

What

[ ] Migration to Material 3

https://material.io/blog/migrating-material-3

[ ] Migrate History to Material 3
[ ] Migrate Scan to Material 3
[ ] Migrate Search to Material 3
[ ] Migrate Compare to Material 3
[ ] Migrate Home to Material 3
[ ] Migrate Lists to Material 3
[ ] Migrate Product page to Material 3
[ ] Migrate Edit mode to Material 3
[ ] Migrate Search by barcode to Material 3
[ ] Migrate Additives to Material 3
[ ] Migrate Login screen to Material 3
[ ] Migrate My Contributions to Material 3
[ ] Migrate Products to be completed to Material 3
[ ] Migrate Preferences to Material 3
[ ] Migrate Category explorer to Material 3
[ ] Migrate Additives explorer to Material 3
[ ] Migrate Allergen alert manager to Material 3
[ ] Migrate Search results to Material 3

Part of

#4169

@teolemon  As per my understanding , we need to replace Theme.MaterialComponents. with Theme.Material3. for themes and Widget.MaterialComponents. with Widget.Material3. for widget styles.


Rethink frontend layout

At the moment, a standard screen has space for about 5 search results. To compare, Hoogle can have 10 on one screen. I'd like to rethink the layout to make it more condensed. Also, the bold text draws a lot of attention and we could try to think of ways to make the actual code the center again. Most of the fields don't actually need a header.
Some ideas to do this:

[x] Remove the distance information. It is not really useful to anyone (except perhaps the developers, who can still get this information from the API).
[x] Merge the filename and module rows into something like Data.Map (dcl:15, icl:30). Perhaps also merge the library row, making it Platform: Data.Map (dcl:15, icl:30).
[ ] Remove the unifier (is it really used by any one except the developers?) or show it in a different way. Hoogle does this with colors, but their code is not highlighted. Another possibility is to add an option to the header to show/hide the unifier.
[ ] Make the header smaller. We could try to put the text and the form next to the image.
[x] Reduce spacing between results by using colours. Hoogle does this nicely, but also a striped table could already work.

When this is done, we should probably also increase the page size (currently 15), which is not really a problem as all the results are computed anyway.

Making the header smaller will look weird when advanced options are turned on. Also, with large fonts just the form alone could be longer than the logo. It wouldn't be a big improvement anyway.
We are not going to remove the unifier, as it is still used by some people (and only shows with type search, and doesn't take a lot of space).


Not defaulting to Select mode when the verse is blank

Verify that verse check is not default to Select mode when the verse is blank

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable


Support for RHEL6.6 and RHEL7 sudo automatic config

This PR adds support for the 'automatic sudo' configuration that is now present in RHEL =>6.6 (F21+).

Add an option for specifying '--no-sudo' for ipa-client-install to completely disable automatic and manual sudo configuration.
Add a new parameter named $needs_sudo_config to determine if the client needs manual sudo confiruation (<6.6).

Otherwise looks good :+1:

Oops - my bad!  How is this?

Perfect, thanks! @joshuabaird Can I release version 2.5 of the module w/ FreeIPA 4 support?


Not able to add the Dataset NOAA_water_database

I am using influxdb i am running the server and i am running my influxdb cli 1.7.8 on local
problem is i am trying to import the data set to learn influx db well. i am following documentation given on https://docs.influxdata.com/influxdb/v1.7/query_language/data_download/
i am  not able to add the data set i was able to download the data set when i try to insert the data set it says    influx -import -path=C:\Users\sshahah\Desktop\NOAA_data.txt -precision=s -database=NOAA_water_database
ERR: error parsing query: found influx, expected SELECT, DELETE, SHOW, CREATE, DROP, EXPLAIN, GRANT, REVOKE, ALTER, SET, KILL at line 1, char 1

Where are you running the command? This command is meant to be run from a terminal. The error message would suggest you're trying to run it from an interactive query prompt or from Chronograf.
 influx -import -path=C:\Users\sshahah\Desktop\NOAA_data.txt -precision=s -database=NOAA_water_database

sure i was trying from Windows CMD i will install chrongraf and give a try
Thanks for response

Sorry, this command won't work in Chronograf. Chronograf only allows you to run InfluxQL queries. The command itself should work. I'm wondering if it's an issue with CMD. Have you tried any other command prompts?

it dosent work on CMD when i say influx on CMD it is not recognized. However i try to open the cli by clicking on exe file once done i can run all commands like show databases but except the import dosent work . is the command for Linux Terminal ?

It will work on any terminal, but you need to make sure the influx binary is on your system $PATH.

Sure I think I didn’t do that I will try that out
Thanks for help
On Fri, Sep 13, 2019 at 4:21 PM Scott Anderson<EMAIL_ADDRESS>wrote:

It will work on any terminal, but you need to make sure the influx binary
is on your system $PATH.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/influxdata/docs.influxdata.com/issues/2411?email_source=notifications&email_token=AJMF5P7E4WAMUJS2W5CNVULQJPY6FA5CNFSM4IWSYQNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6WDABA#issuecomment-531378180,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJMF5PZAGNMWCQRGW2MLGMDQJPY6FANCNFSM4IWSYQNA
.

--
Thanking You,
Soumil Nitin Shah
B.E in Electronic
MS Electrical Engineering
MS  Computer Engineering
+1-646 204 5957


Change to new azurearcdata whl link

Description
Update links to arcdata whl files as we are moving the files to a different location with the motive to remove the old locations.
Related command
az extension add --name arcdata
General Guidelines

[ ] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[x] Have you run python scripts/ci/test_index.py -q locally? (pip install wheel==0.30.0 required)
[x] My extension version conforms to the Extension version schema

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

Thank you for your contribution! We will review the pull request and get back to you soon.

We need to double check with @kairu-ms//@yonzhan /team if updating these vcr recoding's are ok like this since all we ae doing is moving storage endpoint uri or do these get automatically generated for us once we change the index.json

I'm curious why updated recording files which are not related to your extensions?

/azp run

We need to double check with @kairu-ms//@yonzhan /team if updating these vcr recoding's are ok like this since all we ae doing is moving storage endpoint uri or do these get automatically generated for us once we change the index.json

Yes, that's fine


Fix configuration file default value and make error information more detailed

Please see the commit message of this PR.
cc @stevenhorsman

This default value of KBS cert would make the KBS client to read it as a PEM cert, thus always fails to launch.

The unit tests probably need updating to get this path covered?

at the moment users have to specify explicitly, even if a user does not use the feature.
credentials = []

Without this section it could be fine. See the unit test for config example https://github.com/confidential-containers/guest-components/blob/main/confidential-data-hub/hub/src/config.rs#L249-L261

The unit tests probably need updating to get this path covered?

Updated. See https://github.com/confidential-containers/guest-components/pull/726/files#diff-51b4317c4f4b87e6825be8fe3761800028d718fff2c48542e78904a6fc82aba1R303


Support custom certificate for webpack dev server

Feature Suggestion
To be able to run backstage locally using https, the self signed certificate created by the webpack dev server is not trusted, which is a bit sad. So, it only makes sense to offer the possibility to provide another certificate to use instead.
Possible Implementation
As the configuration is generated by backstage-cli, there is little room for customization, we could either provide configuration options for webpack generically, or just for the https section specifically, or as command line options.
Context
Trying to run backstage app locally using https, and want to use a company issued certificate, rather than a self signed one.
I do know we can simply copy the certificate to  node_modules/webpack-dev-server/ssl/server.pem before running, but that is kind of hackish, and it is occasionally replaced when upgrading the package etc..

Is there any update on this?

Don't know that anyone is working on this.
Some pointer in case anyone wants to pick it up is that the webpack-dev-server config where the certificate would be set is over here. The CLI currently houses the app.listen configuration schema, which we would need to extend to cover the HTTPS option. I think it would be best to mimic the backend.listen.https configuration.


[🐛 Bug]: "Failed to retrieve the Cloudflare request context" in app/api route handlers

next-on-pages environment related information
System:
Platform: linux
Arch: x64
Version: #1 SMP Thu Oct 5 21:02:42 UTC 2023
CPU: (4) x64 AMD Ryzen 3 3200G with Radeon Vega Graphics
Memory: 8 GB
Shell: /bin/bash
Package Manager Used: pnpm (8.15.2)
Relevant Packages:
@cloudflare/next-on-pages: 1.9.0
vercel: N/A
next: 14.1.0
Description
Hi there,
I'm building a web app with Next-on-Pages.
I have a lib/db/data.ts file that exports a few functions that retrieve something from a D1 Database. This file looks like this:
export const runtime = 'edge'
import { cache } from 'react'
import { getRequestContext } from '@cloudflare/next-on-pages'
const { env } = getRequestContext()

async function getDatabase() {
    const database = env.CLOUDFLARE_DATABASE
    if (!database) {
        console.error('Database is not available')
        throw new Error('Database is not available')
    }
    return database
}

export const getUser = cache(async (id: number) => {
    const database = await getDatabase()

    try {
        const user = await database
            .prepare(
                `
                // query code
          `
            )
            .bind(id)
            .first()
        return user
    } catch (error) {
        throw new Error(`Error: ${error.message}`)
    }
})

Everything works fine when I import the getUser function in some route like app/user/page.tsx
However, if I were to import and use this function in the exact same way inside app/api/getUser/route.ts, the build will fail with a message like
                         ^

Error: Failed to retrieve the Cloudflare request context.
    at _ (..next/server/app/api/getUser/route.js:14:259)
    at 1838 (..next/server/app/api/getUser/route.js:1:1939)
    at __webpack_require__ (..next/server/edge-runtime-webpack.js:25:42)
    at 6295 (..next/server/app/api/getUser/route.js:1:573)
    at __webpack_require__ (..next/server/edge-runtime-webpack.js:25:42)
    at ..next/server/app/api/getUser/route.js:31:41915
    at webpackJsonpCallback (..next/server/edge-runtime-webpack.js:213:39)
    at ..next/server/app/api/getUser/route.js:1:51
    at Script.runInContext (node:vm:133:12)
    at runInContext (node:vm:287:6)

> Build error occurred
Error: Failed to collect page data for /api/getUser

All files (the api route handler, the page.tsx, and data.ts) have a export const runtime = 'edge' at the start.
Am I missing something?
Reproduction
No response
Pages Deployment Method
None
Pages Deployment ID
No response
Additional Information
No response
Would you like to help?

[ ] Would you like to help fixing this bug?

This was fixed by moving the getRequestContext() call to inside the function:
import { cache } from 'react'
import { getRequestContext } from '@cloudflare/next-on-pages'

async function getDatabase() {
    const { env } = getRequestContext()
    const database = env.CLOUDFLARE_DATABASE
    if (!database) {
        console.error('Database is not available')
        throw new Error('Database is not available')
    }
    return database
}

Hi @thipperz, thanks for the issue 🙂
Sorry I haven't been able to reply to this sooner 🙇
I see that you've closed the issue and I'm glad you've found a workaround, but anyways your original code should work...
so I still feel like this issue's valid and that we need to investigate this further, I'm reopening the issue if that's ok with you 🙂
(PS: I'll try to investigate this soon but I don't know when I'll be able to 😓)

@thipperz I've tried but I don't seem able to reproduce this issue on my side, is there any chance that you could share a reproduction for it? 🙏

Minimal reproduction for this issue: https://github.com/dario-piotrowicz/next-on-Pages-top-level-getRequestContext-bug-repro

[!NOTE]

Everything works fine when I import the getUser function in some route like app/user/page.tsx

I don't get the above... as this bug/issue does seem to effect standard routes too (as you can see from my minimal reproduction) ¯\(ツ)/¯

I don't get the above... as this bug/issue does seem to effect standard routes too (as you can see from my minimal reproduction) ¯_(ツ)_/¯

Hi @dario-piotrowicz, I couldn't reproduce the issue again, perhaps I was mistaken as it was working with npm run dev. However, the build process indeed fails for both API and standard routes.

I'm experiencing the same issue and I would rather not call getRequestContext on every route. This issue seems to have been introduced recently.

Hi @dario-piotrowicz, I couldn't reproduce the issue again, perhaps I was mistaken as it was working with npm run dev. The build process indeed fails for both API and standard routes.

@thipperz thanks for the clarification 🙂 🙏
PS: I experimented with this and it seems like we'll have to go with your solution after all 😅
I'm documenting it properly https://github.com/cloudflare/cloudflare-docs/pull/13371
and will make the error we throw in the build process user friendly trying to make this limitation as clear as possible for the user 🙂 (I wish we could do better but I don't think we can)

I'm experiencing the same issue and I would rather not call getRequestContext on every route. This issue seems to have been introduced recently.

@treboryx the fact is that getRequestContext needs to be run as part of the request handling, calling it globally/unconditionally at the top level is something that we can't support (🥲) but if it's a problem for you
you can use global variables/memoization not to have to call it more than needed.
Also please keep in mind that getRequestContext is practically a getter, it doesn't really instantiate anything or anyways it doesn't have any costly operation so it's (in my opinion) really fine to call whenever you like.

I'm experiencing the same issue and I would rather not call getRequestContext on every route. This issue seems to have been introduced recently.

@treboryx the fact is that getRequestContext needs to be run as part of the request handling, calling it globally/unconditionally at the top level is something that we can't support (🥲) but if it's a problem for you you can use global variables/memoization not to have to call it more than needed.
Also please keep in mind that getRequestContext is practically a getter, it doesn't really instantiate anything or anyways it doesn't have any costly operation so it's (in my opinion) really fine to call whenever you like.

Oh yeah I get that it's just that my code was nicely organized and now I have to use it everywhere.
HOWEVER, I found a solution that seems to work
import { getRequestContext } from "@cloudflare/next-on-pages";

const { env } = process.env.NODE_ENV === "development" ? getRequestContext() : process;

I have to use getRequestContext in development but that doesn't seem to be the case when the application is deployed so I use process instead.

@treboryx yeah.... that should indeed work 👍
Ideally I'd love it if people could not use process.env and just use getRequestContext (I am not a huge fan of having two different ways of doing the same thing) but I am not sure if we're ever going to actually remove the process.env bindings. Anyways that is not deprecated and it's unlikely to get deprecated (yet alone removed) any  time soon, so your solution should be ok 🙂
Alternatively you could just use getOptionalRequestContext, that is totally fine to use in the top level (as soon as you do properly check the truthyness of the value that is).
So, could you maybe try:
import { getOptionalRequestContext } from "@cloudflare/next-on-pages";

const { env } = getOptionalRequestContext() ?? { env: {} };

that should pretty much be the exact same as your solution

in 2024, i still found this problem
i use chat gpt but i cant fix this error

Has anybody found a solution for this? this is what my db/index.ts file looks like and it's unable to detect and use DB binding when deployed on a preview branch with NODE_ENV being set to production while deploying on a non "main" branch.
import { getRequestContext } from '@cloudflare/next-on-pages';
import { drizzle } from 'drizzle-orm/d1';

import * as schema from './schema';

export const runtime = 'edge';

function initDbConnection() {
  const { env } =
    process.env.NODE_ENV === 'development' ? getRequestContext() : process;

  return drizzle(env.DB as D1Database, {
    schema,
    logger: true
  });
}

export const db = initDbConnection();

also, my drizzle.config.ts looks like:
import type { Config } from 'drizzle-kit';
import { defineConfig } from 'drizzle-kit';

export default process.env.DB_LOCAL_PATH
  ? defineConfig({
      schema: './src/db/schema.ts',
      out: './src/db/migrations',
      dialect: 'sqlite',
      dbCredentials: {
        url: process.env.DB_LOCAL_PATH
      }
    })
  : (defineConfig({
      schema: './src/db/schema.ts',
      out: './src/db/migrations',
      driver: 'd1-http',
      dialect: 'sqlite',
      dbCredentials: {
        accountId: process.env.ACCOUNT_ID!,
        token: process.env.D1_TOKEN!,
        databaseId:
          process.env.NODE_ENV === 'development'
            ? process.env.DB_PREVIEW_DATABASE_ID!
            : process.env.DB_PROD_DATABASE_ID!
      }
    }) satisfies Config);


More clear formatting for posts.

Right now it's: feed_name - content - feed_item_link. Place the name and link on a separate line. In markdown, I'd imagine it to look like this:
[feed_name](feed_link): [Post](feed_item_link)

content

Subject line / feed item title can be the same as the content, or too long, so I'd rather not use it instead of the static 'Post' text.

embeds + title-only mode would also be nice.


DeveloperGuide: Add ViewCommand

Added DG for ViewCommand and will add diagrams in a later PR

I realized it was added already for pie chart.


tsconfig.spec.ts fails in MacOS, because /var is actually located in /private/var

I think having something like fs.realpathSync will solve the issue. I will test this and create a pull request later today.
  expect(received).toBe(expected) // Object.is equality

    Expected: "/var/folders/l1/q852l81d1lv95zhblgdvf0gr0000gn/T/tstl-test-FXslwE/tsconfig.json"
    Received: "/private/var/folders/l1/q852l81d1lv95zhblgdvf0gr0000gn/T/tstl-test-FXslwE/tsconfig.js

After some digging seems like this is the problem: https://github.com/nodejs/node/issues/7545
We are calling process.cwd() returning the real path /private/var, while the test just does a simple path.join with /var, causing the mismatch.
Since Node.js seems not to be planning to fix this I think we can go ahead with your proposed fix.


Table: DependsOn, Measure: DependsOn for RLS

Describe the bug
The DependsOn and DependsOn.Deep() are not providing output. I believe these are supposed to work for measures and tables.
To Reproduce
Steps to reproduce the behavior:

Run these in the advanced scripting window:

Model.Tables["Revenue"].DependsOn.Output();
Model.Tables["Revenue"].DependsOn.Deep().Output();
Expected behavior
Expect to see all the direct (& indirect) dependencies of the table. Also expect to see RLS dependencies for security tables that use bi-directional & SecurityFilteringBehavior = BothDirections. Currently this is also not shown as a dependency for the measure dependencies.
Observed behavior
Model.Tables["Revenue"].DependsOn.Output();  outputs to this: TabularEditor.TOMWrapper.Utils.DependsOnList
Model.Tables["Revenue"].DependsOn.Deep().Output(); outputs to a blank list
Model.Tables["Budget"].Measures["Billed Budget"].DependsOn.Deep().Output(); does not include the RLS dependency as described above. This table relates to a Geography table which relates to a security table (so dependencies exist).
Application specifics

Tabular Editor version: 2.12.4

You have it backwards:

X.DependsOn gives you a list of the objects that X depends on. So if X is a measure with the expression: [A] + [B] and [B] is a measure with the expression 2 * [C], then X.DependsOn would return [A] and [B], while X.DependsOn.Deep() would return [A], [B] and [C].
Sounds like you wanted to use X.ReferencedBy which is the opposite of DependsOn. This should let you know if measure [X] is used in an RLS expressions, for example, or if X is a table, whether it's being referenced in any DAX expression. You can also use X.ReferencedBy.Deep() to get objects that indirectly reference X through other objects.

As clarified on e-mail, being able to detect dependencies by filter propagation is outside the scope of Tabular Editor, so I'll mark this as an "Enhancement" rather than a "Bug".

The 'ReferencedBy' and 'DependsOn' methods don't appear to work for tables (and columns). Right now it seems they just work for measures. However, when right clicking on a table and clicking 'Show Dependencies' within the dropdown, it shows 'Objects on which Table X depend', 'Objects that depend on Table X', and 'Show relationships starting from Table X'. These 3 are super useful and would be great to have them show via advanced scripting.

right now it seems they just work for measures

Could you try the following scripts to see if these do what you need:

"Objects on which Table X depend" can be obtained through scripting as: Selected.Table.DependsOn.Keys.Output(); (similar for calc columns, measures and other objects that contain DAX).
"Objects that depend on Table X" can be obtained through scripting as Selected.Table.ReferencedBy.Output(); (similar for columns and measures)
"Show relationships starting from Table X" can be obtained thorugh scripting as Selected.Table.RelatedTables.Output();

Thanks Daniel. It seems the RelatedTables method only shows the first level of the relationship tree. The 'Show relationships starting from Table X' allows you to navigate a tree to see the full chain of relationships. Is it possible to show the full relationship tree using the RelatedTables method? The reason I'm asking is to detect snowflake-schema models (counting the number of relationship generations).

RelatedTables traverses relationships in both directions, which is probably not what you need.
The following script detects all tables that are filtered through another table. The script only considers active relationships. The script does not consider bi-directional filtering.
var snowflakes = new List<string>();
foreach(var t in Model.Tables)
{
    snowflakes.AddRange(
        Model.Relationships
            .Where(r => r.FromTable == t && r.IsActive)
            .SelectMany(r1 => Model.Relationships.Where(r => r.FromTable == r1.ToTable && r.IsActive))
            .Select(r2 => string.Format("'{0}' filters '{1}' which in turn filters '{2}'", r2.ToTable.Name, r2.FromTable.Name, t.Name))
        );
}
snowflakes.Output();

Example output:

Is this sufficient or do you need an explicit count of the relationship generations (in order to detect 2nd, 3rd, etc. order snowflakes)?

Ideally I'm thinking it would be best to have it as a BPA rule that could be set to flag tables which are X-generation snowflake (X being 3 or 4 etc). I would think the table on the 'ToTable' end would be the table that gets set as the highest generation (in your example the 0 member of the list). Thanks!


Fixing arbitrary integers shrinking problem

The current version of the ArbitraryIntegers shrinking process is not working properly because it does not allow shrinking an integer to its neutral value 0. The integers' test suite version on the master branch only succeeds because the current default strategy considers bias and 0 belongs to the set of corner cases.

The following test with the following configuration allows you to replicate the stated issue.

Can we merge this?


2021-07-20 equity dashboard chart data update

Equity dashboard stats updates in this PR may be reviewed on staging - here.
After reviewing, if all looks well, approve and merge this Pull Request.
If there are issues with the data:

Note concerns or issues here by commenting on this PR
Work with Triston directly to resolve data issues
Alert the COVID19 site team in Slack (in the Equity page channel)

Good morning everyone - Here are notes from today's data review. As always, @vargovargo, please do review as needed!!
:warning: The Blue Box numbers appear identical to last week, which I wouldn’t expect. Would it be possible check if the numbers successfully updated?
:heavy_check_mark: Everything else seems normal, and I observe no major red flags!
:bulb: Several noticeable highlights this week:
:bulb: Noticeable increases occur in all Case/100K rates — the largest rates of increase across all categories observed in the past month. All values appear reasonable.
:bulb: Deviating from consistent decreases over the past 10 weeks, statewide testing/100K increases slightly this week. This is reasonable, as, while certain categories continue to show decreases in testing/100K (i.e., NHPI, White), others show increases (i.e., Black, Multi-Race).
:bulb: Income bracket cases/100K and statewide case rate nearly double this week. Unexpectedly, $60-80K case rate > $40-60 = $0-40K (by 0.1)
:bulb: Statewide cases/100K = $100-120K bracket cases/100K (for the past three weeks, it was between $60-80K & $80-100K bracket value)
:bulb: Statewide Positivity Increase: 1.3 (Last week: 0.5) — double last week’s rate of increase
Thank you!
1. Blue Box Updates:
:warning: The Blue Box numbers appear identical to last week, which I wouldn’t expect. Would it be possible check if the numbers successfully updated?
2. Death Rate/100K by R&E:
:heavy_check_mark: All numbers are reasonable and stable (stay at 0, 1 or <11) — identical to last two weeks.
:heavy_check_mark: % of COVID-19 deaths statewide changed significantly (≥0.5%) for the following categories:
Black: ~2% increase in % of deaths statewide
White: ~1.3% increase in % of deaths statewide (contrast to last week’s ~2% decrease)
Latino: ~2% decrease in % of deaths statewide (contrast to last week’s 2% increase)
Asian American: ~1% decrease in % of deaths statewide (similar to last week’s ~1% decrease)
3. Case Rate/100K by R&E:
:bulb: Noticeable increases occur in all Case/100K rates — the largest rates of increase across all categories observed in the past month. All values appear reasonable.
:heavy_check_mark: Cases relative to percentage of population in CA did not change significantly (≥0.5%) for any categories except:
Asian American: 0.6% increase in % of cases statewide
Latino: ~1.5% decrease in % of cases statewide (similar to last week’s ~2% decrease)
4. Testing Rate/100K by R&E:
:bulb: Deviating from consistent decreases over the past 10 weeks, statewide testing/100K increases slightly this week. This is reasonable, as, while certain categories continue to show decreases in testing/100K (i.e., NHPI, White), others show increases (i.e., Black, Multi-Race).
:heavy_check_mark: Testing relative to percentage of population in CA did not change significantly (≥0.5%) except for the following categories:
White: 0.7% decrease in % of testing statewide
Latino: 0.6% increase in % of testing statewide (contrast to last week’s 0.8% decrease)

5. Mortality rate/100K vs. Case rate/100K
:heavy_check_mark: Sanity Check — Mortality rate/100K < Case rate/100K for all categories (as expected).
6. Community case rate/100K by median annual household income bracket:
:bulb: Income bracket cases/100K and statewide case rate nearly double this week. Unexpectedly, $60-80K case rate > $40-60 = $0-40K (by 0.1)
:bulb: Statewide cases/100K = $100-120K bracket cases/100K (for the past three weeks, it was between $60-80K & $80-100K bracket value)
7. HE Metric:
:heavy_check_mark: HE Quartile & Statewide Positivity continue to increase (increasing trend began 06/22/21).
:heavy_check_mark: HE Quartile Increase: 1.0 (Last week: 0.9 increase)
:bulb: Statewide Positivity Increase: 1.3 (Last week: 0.5) — double last week’s rate of increase
:heavy_check_mark: X-Axis (Dates) successfully extended.
8. Data completeness (DC):
:heavy_check_mark: DC values predominantly show no significant changes (≥0.5%) except for the following:
R&E Cases DC: decreased by 1%
SO Deaths DC: decreased by 1.5% (similar to last week’s 0.5% decrease)

I apologize @sindhuravuri the staging server did not get the latest data in this update. I refreshed it and now https://staging.covid19.ca.gov/equity/ is pulling the data from this refresh.
The Pacific Islander numbers in the blue box are different from production now

Thank you @aaronhans!
@vargovargo The updated numbers look reasonable to me (Boxes 2 & 4 - PI & income - changed)!


Add Hosted Zone to terraform

Overview
Add the potsdam.geotrellis.io hosted zone and associated Route53 records to the Terraform configuration.
Notable changes

Add terraform 0.9 support
Add Terraform resources for the potsdam.geotrellis.io external hosted zone and records.
Simplify security group rules

The Container Instance security group is configured to allow all egress traffic. I removed any redundant egress rules.
The current security group configuration uses a combination of aws_security_group ingress/egress blocks, and aws_security_group_rule resources. Per the Terraform docs, this is not recommended, so I removed all of the security_group_rule blocks and added corresponding ingress/egress rules to the aws_security_group.

Pass the nginx and api-server image versions to Terraform through scripts/infra instead of hardcoding them.

Testing
$ vagrant provision
$ vagrant ssh
vagrant@vagrant-ubuntu-trusty-64:/vagrant$ export RV_SETTINGS_BUCKET=rastervision-viz-staging-config-us-east-1
vagrant@vagrant-ubuntu-trusty-64:/vagrant$ export GIT_COMMIT=ce8b3db
vagrant@vagrant-ubuntu-trusty-64:/vagrant$ ./scripts/infra plan

Fixes #7

This is awesome.
Question: I see that the route53 is an external hosted zone. Is this because the DNS is registered with a different AWS account? Was there some manual steps on the other AWS account that were required for this to work?

That's correct. In order to delegate DNS for potsdam.geotrellis.io to the R&D account, I needed to setup an external hosted zone here, and add the nameservers to a NS record in the main geotrellis account.

To clarify a bit on the naming, "external" in this context translates to it being public-facing vs. internal, which would be private to the VPC.

Are the nameservers created by this terraform process, or they exist in the azavea-research account w/ the route 53 service beforehand, and you need to link the azavea-research account nameservers to the geotrellis account Route 53?

When I created the hosted zone with Terraform, the nameservers were created automatically as part of the process. I looked up the NS records in the AWS console and added them to Route53 in the main GeoTrellis account.

Got it. Thanks for explaining that to me.


Tree fade out remain after escaping rename file

VSCode Version: 1.38.1
OS Version: Window 10

Steps to Reproduce:

F2 to rename a file
Escape

The tree fade out activated during rename is not remove when escaping.
You have to reload or rename a file to remove this.

Fixed in latest. Checkout insiders and the next stable release. If you still see this let us know and we will reopen thanks.


feat: check pricing data every 30 minutes

Fixes #none

Proposed Changes

Check the AWS pricing data every 30 minutes

Release Note

/lgmt


[#noissue] Rollback maven plugins-module profiles

Not IDE friendly

Codecov Report

Merging #6472 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #6472      +/-   ##
==========================================
- Coverage   39.56%   39.54%   -0.03%
==========================================
  Files        3083     3083
  Lines       91951    91951
  Branches    11886    11886
==========================================
- Hits        36379    36358      -21
- Misses      52564    52583      +19
- Partials     3008     3010       +2

Impacted Files
Coverage Δ

...uster/zookeeper/exception/ConnectionException.java
0% <0%> (-28.58%)
:arrow_down:

.../cluster/zookeeper/ZookeeperExceptionResolver.java
24.13% <0%> (-17.25%)
:arrow_down:

...pc/server/LoggingServerMessageListenerFactory.java
90% <0%> (-10%)
:arrow_down:

...pinpoint/profiler/instrument/AccessorAnalyzer.java
57.14% <0%> (-8.58%)
:arrow_down:

...rc/main/java/com/navercorp/pinpoint/test/Item.java
66.66% <0%> (-6.67%)
:arrow_down:

...r/zookeeper/CuratorZookeeperConnectionManager.java
68.75% <0%> (-6.25%)
:arrow_down:

...m/navercorp/pinpoint/web/util/ThreadDumpUtils.java
33.33% <0%> (-5.72%)
:arrow_down:

...r/zookeeper/ZookeeperClusterDataManagerHelper.java
80% <0%> (-4.45%)
:arrow_down:

...ntext/thrift/ThreadDumpThriftMessageConverter.java
89.28% <0%> (-3.58%)
:arrow_down:

...itor/metric/deadlock/ThreadDumpMetricSnapshot.java
68.23% <0%> (-2.36%)
:arrow_down:

... and 7 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fddc347...9b8a45b. Read the comment docs.


Sentiment Analysis documentScores is unavailable

Hi to all,
According to the official Microsoft Sentiment Analysis API documentation, both 3.0 and 3.1 version of the API return a field called confidenceScores that contains the predicted scores associated with the labels (positive, negative and neutral) related to the analyzed document.
From documentation:

Sentiment Analysis in version 3.x applies sentiment labels to text, which are returned at a sentence and document level, with a confidence score for each.

When we call the API through the pyspark mmlspark.cognitive.TextSentiment module (we use the mmlspark 1.0.0-rc3 version on a Azure Synapse Spark Pool v2.4), it seems that the confidenceScore is named in the output dataframe as documentScores.
However, this field results always undefined as shown below:
sentiment = (TextSentiment()\
    .setTextCol(text_column)\
    .setOutputCol("output")\
    .setSubscriptionKey(service_key)\
    .setLocation(sentiment_location)\
    .setLanguage(sentiment_language)\
)

display(sentiment.transform(df).select("Analized_Text", col("output")[0].getItem("documentScores")))

Output:

@Stargatto this is fixed in master and could possibly be in the spark3 version on synapse. Would you mind switching over to the spark 3 pool to see?

@mhamilton723 yes, using an Apache Spark v3 pool in Azure Synapse, confidence scores are now present with the correct names. Thank you!


Do capabilities support key rotation?

Should invoker be limited to DIDs or DID_URLS ?
See https://github.com/decentralized-identity/confidential-storage/pull/142/files#r541971789

I favor specifying the invoker to be a DID. I agree we should limit ourselves to one or the other in order to simplify implementations (DID resolver vs DID URL de-referencer).
The semantics around DID verification relationships are well-established.
It allows key rotation.
Allows use cases requiring deactivation (such as a user ending their relationship with a service provider).
There's always did:key for use cases that want to constrain access to a single key.


[rtop] Odd printing of polymorphic variants

Rtop Session
Reason # let f = fun | `Ok(x) => x == 1;
let f: [< `Nope | `Ok(int) ] => bool = <fun>;
Reason # let g = fun | `Ok(x) => x == "!!!" ;
let g: [< `Ok(string) ] => bool = <fun>;
Reason # let h = x => f(x) && g(x);
let h: [< `Okstring & int ] => bool = <fun>;

Expected
Reason # let f = fun | `Ok(x) => x == 1;
let f: [< `Nope | `Ok(int) ] => bool = <fun>;
Reason # let g = fun | `Ok(x) => x == "!!!" ;
let g: [< `Ok(string) ] => bool = <fun>;
Reason # let h = x => f(x) && g(x);
let h: [< `Ok(string & int) ] => bool = <fun>;

This is probably a bug in the outcome printer cc @IwanKaramazow


Exception when using StatefulBuilder in a StatelessWidget Tab View

Steps to Reproduce

Create a default Tab Controller with multiple tab views.
In the first tab view, I have a StatelessWidget which returns a StatefulBuilder based widget.
When I scroll to the second tab, I get the below mentioned exception in log section.

Code Use
class ImageItem extends StatelessWidget {
  @override
  Widget build(BuildContext context) {

      return StatefulBuilder(
           builder: (BuildContext context, StateSetter setState) {
               setState(() {
                 likesCount = post.likesCount;
               });

              return ActionChip(label: Text(likesCount);
      });
  }
}

Since I am using setState inside a StatelessWidget(using StatefulBuilder), I can not use dispose() method as mentioned in the exception.
There should be a way to handle this inside StatefulBuilder widget.
Logs
E/flutter ( 7147): [ERROR:flutter/shell/common/shell.cc(188)] Dart Error: Unhandled exception:
E/flutter ( 7147): setState() called after dispose(): _StatefulBuilderState#09a22(lifecycle state: defunct, not mounted)
E/flutter ( 7147): This error happens if you call setState() on a State object for a widget that no longer appears in the widget tree (e.g., whose parent widget no longer includes the widget in its build). This error can occur when code calls setState() from a timer or an animation callback. The preferred solution is to cancel the timer or stop listening to the animation in the dispose() callback. Another solution is to check the "mounted" property of this object before calling setState() to ensure the object is still in the tree.
E/flutter ( 7147): This error might indicate a memory leak if setState() is being called because another object is retaining a reference to this State object after it has been removed from the tree. To avoid memory leaks, consider breaking the reference to this object during dispose().
E/flutter ( 7147): #0      State.setState.<anonymous closure> (package:flutter/src/widgets/framework.dart:1097:9)
E/flutter ( 7147): #1      State.setState (package:flutter/src/widgets/framework.dart:1123:6)
E/flutter ( 7147): #2      ImageItem.actionColumn.<anonymous closure>.<anonymous closure> (package:silkthread/widgets/image_item.dart:197:19)
E/flutter ( 7147): #3      _RootZone.runUnary (dart:async/zone.dart:1379:54)
E/flutter ( 7147): #4      _FutureListener.handleValue (dart:async/future_impl.dart:129:18)
E/flutter ( 7147): #5      Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:642:45)
E/flutter ( 7147): #6      Future._propagateToListeners (dart:async/future_impl.dart:671:32)
E/flutter ( 7147): #7      Future._complete (dart:async/future_impl.dart:476:7)
E/flutter ( 7147): #8      _SyncCompleter.complete (dart:async/future_impl.dart:51:12)
E/flutter ( 7147): #9      _RootZone.runUnary (dart:async/zone.dart:1379:54)
E/flutter ( 7147): #10     _FutureListener.handleValue (dart:async/future_impl.dart:129:18)
E/flutter ( 7147): #11     Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:642:45)
E/flutter ( 7147): #12     Future._propagateToListeners (dart:async/future_impl.dart:671:32)
E/flutter ( 7147): #13     Future._complete (dart:async/future_impl.dart:476:7)
E/flutter ( 7147): #14     _SyncCompleter.complete (dart:async/future_impl.dart:51:12)
E/flutter ( 7147): #15     _AsyncAwaitCompleter.complete.<anonymous closure> (dart:async/runtime/libasync_patch.dart:33:20)
E/flutter ( 7147): #16     _microtaskLoop (dart:async/schedule_microtask.dart:41:21)
E/flutter ( 7147): #17     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50:5)

Output of running `flutter doctor -v is below.
[√] Flutter (Channel beta, v0.10.2, on Microsoft Windows [Version 10.0.17134.345], locale en-IN)
    • Flutter version 0.10.2 at F:\03. System Paths\flutter
    • Framework revision d8cbb80206 (2 weeks ago), 2018-10-26 01:30:21 -0400
    • Engine revision 6c2ade9fa2
    • Dart version 2.1.0-dev.8.0.flutter-bf26f760b1

[√] Android toolchain - develop for Android devices (Android SDK 27.0.3)
    • Android SDK at C:\Android\sdk\
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-27, build-tools 27.0.3
    • ANDROID_HOME = C:\Android\sdk\
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)
    • All Android licenses accepted.

[√] Android Studio (version 3.0)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin version 22.2.1
    • Dart plugin version 171.4424
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)

[√] IntelliJ IDEA Community Edition (version 2018.2)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2018.2.5
    • Flutter plugin version 30.0.2
    • Dart plugin version 182.5124

[!] VS Code, 64-bit edition (version 1.25.1)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension not installed; install from
      https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

[√] Connected device (1 available)
    • MotoG3 • <IP_ADDRESS>:5555 • android-arm • Android null (API null)

SO Question: https://stackoverflow.com/questions/53248230/using-dispose-when-using-statefulbuilder-in-a-statelesswidget#53248230

The code as written here doesn't explain the crash described.
It probably boils down to https://github.com/flutter/flutter/issues/28454 though.

Closing with explanation given by Hixie above.  #28454 is tracking the presumed underlying issue.


DSA user - Reservation Tab -  “User submission” filter ( 'DSA Submissions’ as Default).

DSA user - Reservation Tab -  “User submission” filter ( 'DSA Submissions’ as Default).


Update sbt-typelevel-ci-release, ... to 0.7.4

About this PR
📦 Updates

org.typelevel:sbt-typelevel-ci-release
org.typelevel:sbt-typelevel-mergify

from 0.4.22 to 0.7.4
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.typelevel" }
}]

labels: sbt-plugin-update, early-semver-major, semver-spec-minor, version-scheme:early-semver, commit-count:1

Superseded by #151.