stm32f103 - a few minor questions and feedback / 1st impressions

Hi there,
I am very pleased with this upgrade kit. And grateful for it. My prayers answered. However i did notice a few things inspecting the PCB. And just wanted to let you know. In case you decide to make revisions or updates for future runs.
Most of these are minor small points. Nothing really too important. So please don't take it as any criticism - you have done an excellent work. And with all the most important aspect really well done.
You can see here is a numbered list, for each point.

Is there any use here for RTC battery? Is it meant for having a clock or something? Are settings not need RTC, but instead they stored and remembered in the flash - yes? ...Because if there is no need for it at all, then I can instead cut the trace. And re-use those same terminal points for jumping to some other pins. With a mod wire. Please confirm if it does not matter.
When soldering this GND pad, it was more difficult. Because of course the ground plane. However maybe if you make some cut out (gap) around the GND pad... then that will thermally isolate enough for an easier soldering experience. This is good for example here the LCD screen does not draw much current, so the ground connection is not so critical. It not matter (for me). But maybe some new user or person with a bad soldering iron. Then you can help them not to struggle so much.
Here I can see you break out all the unused GPIOs - great! very good. However in the middle of this header you put the only breakout for the SWD debugging / programmer IO (SWD_CLK and SWDIO). This is not so good to take here (for SWD debug). Because there is no GND or +3v3 nearby. And no NRST pin. So what you want to do is keep it there. But also add dedicated separate SWD debug port. And include the other useful pins next to them. Perhaps something like this: [ 0v, SWD_CLK, SWDIO, 3v3, NRST ]. Or however you want to include them.
This is NRST, ok no problem. I checked with DMM
Buzzer polarity: I was not so sure which way around to install it. However reading online it seems to depend on the device whether polarity matter (or not). But I did check and got higher voltage from one side, which I guess means it has more space to move on the top side... it does not matter for me. I don't mind at all. Just thought to mention it. As perhaps it can make the buzzer sound louder (or more quiet). By reversing the polarity. Which is useful, to the preference. Of course there are also other easy ways to make it quiet. So no problem
What are these for?
Here is BOOT0. It is also useful for programming. However I could not find the trace, or know if the leg is broken out to any pin. I think this is good idea to make a pad for. In case we need to do programming for the open firmware. Typically you just make a 3 pin jumper, [ 3v3, BOOT0, GND ]. To pull it high or low (while flashing). Otherwise it floats internally

So that is all I can see here for suggestions to improve the PCB.
Programming / Debugging

Measuring the current for passively powering the 3v3 rail from the programmer. It draws only 43mA, which is great. Enough for the programmer to power the device during flashing etc. Without browning out. OK then!
While for passive live debugging (independent power). Then we do not connect the 3v3 pin. Only the GND pin, to maintain a ground reference.
For next steps, I have now made a programming cable (for SWD). To try connecting and flashing etc.

Actually you did a really great job for the firmware. I do not plan to change very much. Except maybe if I require more than 3 presets. Then perhaps the buttons can be changed to scroll through numbered list of presets. Up, down, and select. Instead of directly switching to the preset.
However I will not add this until I really know that I need to keep more than 3 presets. So perhaps it won't be needed, then I will not add this.
And of course, as you also mention in your video: it is great to use the GPIO header, for connecting another slave device to control. For example fume extractor on/off. Or for attaching another input device, such as a foot switch pedal(s). So that hands are free. Thank you so much my friend!

WOW, thanks for the feedback. Let's see if I can answer your points, let me know if I miss anything.
1- I'm not using the RTC for anything and it might not even make sense to have this broken out but I thought someone could find a use for it. All the settings are indeed stored to flash so a battery is not required, this would only be used for time keeping and for this you would need to solder a 32.768kHz crystal and the respective load capacitors (Y1, C9, C10). To answer your question, yes you can cut the traces and use for something else but all the pins are already broken out to the EXP header.
2- I didn't have this issue while soldering, the pad actually has thermal reliefs, I might have to check this as you make a good point with with the cheaper soldering irons. I actually widened the pads for the JST's and the THT resistors for the RP2040 version as they turned out quite small on this board. To be honest I don't know if I will continue to offer the kits, it turns out it takes a lot more time to put all the kits together than to actually solder everything.
3- I actually never program this with the SWDIO and SWCLK pins, I initially flash the bootloader with the TX and RX pins and then I just use USB to upload the firmware. I will take this into consideration in the next revision.
5- Yes, I forgot to edit the footprint's silkscreen, that + should not be there, as this is a passive buzzer the polarity should not matter, it only changes the direction the piezo element bends to, I didn't notice any volume difference on the boards I soldered. I already fixed this for the RP2040 version.
6/7- These are BOOT 0 and BOOT 1 they are set with a solder jumper but if you want to thinker with the board you can remove the solder and solder pins and use those tiny header jumpers 😉
For my daily use 3 presets are enough, I use one for heatshrink one for normal rework and one for higher temps, for anything else I just use the pots. You have some nice ideas I'm eager to see some hacks on my board hehe

Hello again! And thanks for these detailed replies. Very good
Here below explained is a very important point about 6/7. Thanks so much for explaining what those B0 and B1 were indeed connected to the boot0 pin an the boot1 pin.
This is the place where I needed to know how to change something, in order to get SWD working. Otherwise SWD does not connect (no response from target).
For some reason ST decided for a logic truth table, that having BOTH these pins set LOW (=GND)... then it breaks SWD. And it won't connect. This you have bridged on these inital batch of units by default BOTH to GND before shipping. Perhaps is might be something which you later on decide change for future units going forwards. Don't worry it's really simple to fix.
So here is my own direct findings from this evening;

boot0
boot1
swd
best one?

0
0
fail

0
1
works
<-- this

1
0
works

1
1
works

And here is the clue, which I found on the internet, somewhere on ST community forum (probably just taken from datasheet)

As you can see (rather not-helpful). But the behaviour for 0,0 is undefined. Which is silly they should know better! but heh :)
So why bother to go to all this trouble to make sure that SWD is working? Well to answer that...
In particular there are certain technical reason(s) why to now strongly prefer to use SWD protocol for both flashing and debugging. The a big reason primarily is convenience in PIO developer environment, where SWD interface allows the IDE to automatically flash, then reboot the chip. Then also automatically connect to the serial monitor (just like the arduino serial monitor). Which is to say... this is better than USB HID flashing protocol (which is broken).
Meybe you find rx/tx serial flashing just as easy (like arduino). However then you cannot do in situ hardware debugging. (with 0 effort, it's all over same cable). And also it occupies those 2 tx/rx pins.... well swd also is only 2 pins protocol. So you free up the serial port. And the USB port too. With SWD you can still debug them like (as is over separate dedicated link), while they are in use. It does not occupy them / block for running your application, or require rebooting into different 'fashing mode' etc. :+1:

So with this minor change I can now connect over SWD (using OpenOCD program, in linux). And dump the existing flash to back it up (in case I brick my device later on). And this then lets me try flashing myself. Not had time to play with yet. Just took a dump to finally report a successful connection. Is working! Very pleased / happy with this situation.
Here is the command I used to connect after pullint b1 = HIGH. This commant is for taio TUMPA v2 programmer. So to be clear: you will need a somewhat different cmdline to connect using other programmer model, such as the very popular STLINK v2. You will need to specify different config .cfg file to load. So that openocd program can know how to talk to other model of programmer device. But that configuration part is just to establish the connection. It does not affect the communication over telnet, to send the commands sent on the SWD link.
openocd -s tcl -f interface/ftdi/tumpa.cfg -f interface/ftdi/swd-resistor-hack.cfg -c "transport select swd" -f target/stm32f1x.cfg -c "reset_config srst_only connect_assert_srst"

Open On-Chip Debugger 0.10.0+dev-01266-gd8ac0086-dirty (2020-05-27-14:47)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
none separate

Info : FTDI SWD mode enabled
Warn : Transport "swd" was already selected
swd
srst_only separate srst_nogate srst_push_pull connect_assert_srst

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x1ba01477
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : stm32f1x.cpu: external reset detected
Info : starting gdb server for stm32f1x.cpu on 3333
Info : Listening on port 3333 for gdb connections

then you open up a 2nd terminal window, and telnet into the running openocd server:
telnet localhost 4444
Trying <IP_ADDRESS>...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> flash list
{name stm32f1x base 134217728 size 0 bus_width 0 chip_width 0}
> flash read_bank 0 boot01.bin
device id = 0x20036410
flash size = 64kbytes
wrote 65536 bytes to file boot01.bin from flash bank 0 at offset 0x00000000 in 0.908111s (70.476 KiB/s)

also you can query the chip for it's memory may layout too,
> dap info
AP ID register 0x14770011
	Type is MEM-AP AHB3
MEM-AP BASE 0xe00ff003
	Valid ROM table present
		Component base address 0xe00ff000
		Peripheral ID 0x00000a0410
		Designer is 0x0a0, STMicroelectronics
		Part is 0x410, Unrecognized
		Component class is 0x1, ROM table
		MEMTYPE system memory present on bus
	ROMTABLE[0x0] = 0xfff0f003
		Component base address 0xe000e000
		Peripheral ID 0x04001bb000
		Designer is 0x4bb, ARM Ltd.
		Part is 0x0, Cortex-M3 SCS (System Control Space)
		Component class is 0xe, Generic IP component
	ROMTABLE[0x4] = 0xfff02003
		Component base address 0xe0001000
		Peripheral ID 0x04001bb002
		Designer is 0x4bb, ARM Ltd.
		Part is 0x2, Cortex-M3 DWT (Data Watchpoint and Trace)
		Component class is 0xe, Generic IP component
	ROMTABLE[0x8] = 0xfff03003
		Component base address 0xe0002000
		Peripheral ID 0x04000bb003
		Designer is 0x4bb, ARM Ltd.
		Part is 0x3, Cortex-M3 FPB (Flash Patch and Breakpoint)
		Component class is 0xe, Generic IP component
	ROMTABLE[0xc] = 0xfff01003
		Component base address 0xe0000000
		Peripheral ID 0x04001bb001
		Designer is 0x4bb, ARM Ltd.
		Part is 0x1, Cortex-M3 ITM (Instrumentation Trace Module)
		Component class is 0xe, Generic IP component
	ROMTABLE[0x10] = 0xfff41003
		Component base address 0xe0040000
		Peripheral ID 0x04001bb923
		Designer is 0x4bb, ARM Ltd.
		Part is 0x923, Cortex-M3 TPIU (Trace Port Interface Unit)
		Component class is 0x9, CoreSight component
		Type is 0x11, Trace Sink, Port
	ROMTABLE[0x14] = 0xfff42002
		Component not present
	ROMTABLE[0x18] = 0x0
		End of ROM table

$ md5sum boot01.bin
9f481217d0d13ab66bafd720a921072b  boot01.bin

$ hexdump boot01.bin | head -20
0000000 2800 2000 00f1 0800 0139 0800 0139 0800
0000010 0139 0800 0139 0800 0139 0800 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0139 0800
0000030 0139 0800 0000 0000 0139 0800 0139 0800
0000040 0139 0800 0139 0800 0139 0800 0139 0800
*
0000090 04f9 0800 0139 0800 0139 0800 0139 0800
00000a0 0139 0800 0139 0800 0139 0800 0139 0800
*
00000e0 0139 0800 0139 0800 0139 0800 f85f f108
00000f0 2100 f000 b804 4b0b 585b 5043 3104 480a
0000100 4b0a 1842 429a f4ff aff6 4a09 f000 b803
0000110 2300 f842 3b04 4b07 429a f4ff aff9 f000
0000120 fa45 4770 1918 0800 0000 2000 02c8 2000
0000130 02c8 2000 030c 2000 f7ff bffe 4770 4770
0000140 4770 2803 bf8c 2002 2000 4770 4770 0000
0000150 4b03 681b 7a9b b113 4b02 2205 601a 4770
0000160 0304 2000 0310 2000 4770 4770 4770 4770
0000170 4770 4770 4b01 2204 601a 4770 0310 2000
0000180 b510 f000 fc77 4b21 4a21 681b 2400 6812

next time, I shall try compiling, flashing etc. in vscode. Using platformIO ide. However 1st I must convert your project into a PIO directory layout. And rename / move the source code files about. For example: main.INO ---> src/main.cpp
Looking forwards to this :)

Hi again. Just forgot to mention, if ever adding a dedicated SWD port...
This is just only a suggestion, because there is no standard, and is different pinout on official ST discovery boards. However most people get the 'blue pill' or the 'black pill', and they have this header:
stm32 Blue pill:

stm32 Black pill:

Great work. I can definitely ship the boards with BOOT 1 set high, I usually set BOOT 0 high and BOOT 1 low to upload the bootloader over t/rx and then just move BOOT 0 to low (and upload the firmware over USB as this way I also make sure the USB is working correctly) but as long as everything works as it should it's no problem for me to set BOOT 1 high too.
Moving to platformio is something I'm looking to do for a loooong time as arduino IDE is way behind, I always say to myself "this is the last project I'm going to do on arduino ide" but when I'm in the mood to program (which to be honest doesn't happen often) I always end up opening arduino ide as I can start right away and it doesn't require me to watch a tutorial to figure out how everything works like setting the board and what not, hope I finally switch over on the next project 😅
Your suggestions are much appreciated 👍

Sure man! Hey if you inevitably get stuck in any places with switching over PIO then don't be afraid to ask for some assistance. You can email me (dreamcat4 at gmail) with the problem. And will try my best to get you past such stuck point.
But am not so familiar with windows specific problem (being on linux). For example installing python on windows, or openOCD on windows. But they should probably do those part in the official vscode extensions / installers

OK so here is now the same command, but modified for the more popular STLINK v2 programmer:
openocd -d4 -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg -c "reset_config srst_only connect_assert_srst"

This is the recommended device for SWD connection within platform io environment. Here is an example of the STLINK v2 looks like,
https://www.aliexpress.com/item/32792513237.html

Hey, sorry for the late reply.
I do have an STLink v2, used it before to flash a tv set top box.
I just noticed that setting BOOT1 high actually breaks the USB communication so I can't ship the boards like this.

sure man no problem. what i would suggest here is to install jumper headers, instead of solder bridges. and also more clear label that these are for boot0 and boot1 pins. not to confuse people thinkink its gpios port b0 and b1.
the other thing we can do is improve here the markdown Readme documentation here with annotated images and arrows / comments.  (or as a wiki if you prefer instead)
actually i have now a few photos which is suitable for that purpose. just have not gotten around to organising it properly. my priority has instead been tweaking the source code. to compile in PIO / vscode. which is coming soon will be uploaded to my fork

Yes next batch of PCBs will have a better label for the boot pins.
Most people are probably never going to change the state of the boot pins so I don't think I will solder the extra headers and include the jumper but, who knows, maybe in the future.
I want to write a small instructions manual with all the information but I haven't had much time as I'm working on several projects simultaneously.

Huh, it's not known to me, for why initial connection failed over SWD, with both boot0 and boot1 set to GND. Perhaps it's something to do with this device (f103 chip), or otherwise the maple bootloader. You see I have only used before the 'black pill' with simultaneous serial + SWD both running together. And black pill is newer stm32f4xx series. With more features and new HAL / IO subsystem.
Anyway, today I did the following things:

Issued this command in openocd session: stm32f1x unlock 0. Although not sure if that was even necessary, because of other issue occuring at the same time.
Set default for serialOutput = 1;
Increment firmware version --> 102
Re-flashed the chip within PlatformIO, over STLINK

Next will reassemble the whole unit. And check it's working and operating as normal. To know that the new firmware build is all works the same as before. For example that the exact library dependencies were chosen correct.
Also I noticed and can confirm the arduino serial device /dev/ttyACM0, it does not appear unless I have set the both boot0 and boot1 back to GND. So I have now done that after the re-flashing. In order to check display on the serial port.
BTW why is serial output disabled by default in the options? Is there some negative effect on the performance, or something else that it causes a problem?

What's new on 102?
Once again since most people won't use the serial output I do not see the need to ship the boards with it enabled, the serial prints will of course increase the loop time but shouldn't have any significant effect on performance.
Serial can be enabled/disabled by a long press of any of the two arrow keys and the state is saved to flash.

Sorry I did not make myself clear enough....
The reason i want the serial output is to check the firmware is functioning after flashing. Same for the firmware version to check there is new version been flashed. It's just for my own testing purpose here.
The thing is that getting a connection from the computer with USB serial is also dodgy. Because the length of the USB cables, and difficulty powering the board etc.
Anyhow I have just reassembled everything. And it does generally seem to be working, except for the display. Which is completely black.
This may be some issue with my device.... or it could be an issue with the LCD display library, which is chosen by the library dependancies of PIO. Or perhaps it could be some other issue with the code migration. IDK
However I have kind of run out of time to look into it further. What I need to do is reflash the original firmware image, and see if the display works. To rule out hardware issue. Then after that investigate the source code a bit more. Or Visa versa (both ways).
But while I have run out of time here. Meantime you can see / browse the code changes on my new branch. To look at what I have been doing to get it to compile in platformIO environment. (and it also includes you last changes for the farenheight steps)
https://github.com/dreamcat4/Best-Improvement/commits/feature/convert_to_platform_io
Good day

So are you not using serial over USB?
You can power the entire board with USB without any issues if you bridge the two pads next to the micro USB connector or you can power the board over the jst connector that connects to the motor controller board and still use USB (make sure the bridge is open if you power it this way). The solder jumper is open by default so there is no backfeed of the 5v to the computer and this way you can turn the station off even if you keep it connected to a powered USB. The rp2040 version will have a diode footprint instead of the solder bridge, I might also add a 2 pin header footprint so it is easier to enable/disable usb power if needed.
About the display, I test all the boards before shipping so I doubt it is an hardware issue with my board but let me know if you can't get it working.  Is the backlight on?
Nice I will have a look at your code.

Uh yeah i guess i could power it with the ESC connector, +15v dc from my bench PSU. That would make more sense, than trying to power over USB. Because usb power is not so great here (for me, with these cables I have). So will leave the bridge open
Yes, the backlight comes on, however the LCD itself is all black. Crystals are twisted. No i do not think your PCB is the reason. It's more likely other issue for example the LCD library, maple framework etc.
The other issue I forgot to say  was the heater is not coming on. Actually I was concerned maybe if the previous guy destroyed the heater element (because the fan was broken, not coming on to be cooling the heater enough). However just now I measure 49.7 ohms between the heater -+ terminals. Which seems normal i guess we will get there eventually.
First must look into the LCD display

@RandomHacks-Git ok so...
if you remember i had some connection issues with the programmer. This turned out to be bad swclk and swdio lines on my programmer cable. One of the header pins was only half engaged (the little 'click' in the plastric plug). And also these data and clock lines were twisted together. which is bad because it creates cross-talk, between those lines.
After noticing and fixing the cable. Then have flashed back the original firmware backup (from 1st earlier dump in openocd).... that was all easy afterwards. Also did have to move the jumper boot1, and return it back again after flashing. So that the firmware would boot. And then was OK working back again
=====
My display hardware, with your upgrade board installed. It all functions OK, the LCD display works great. This means the LCD display issue (black screen). It exists somewhere in the PIO firmware build, or in the upstream LCD library. For those code changes I made let us see now....
Can you please confirm... Is this the correct version of the LCD library to use? Or should it be different library here>
https://github.com/dreamcat4/Best-Improvement/blob/feature/convert_to_platform_io/platformio.ini#L40
I had some minor small fixes to get it to work under linux, But nothing important was changed. Here:
https://github.com/dreamcat4/HT1621/commits/master
It's based on the last commit was hash commit 1ca058d2d677b130cba23216641073719817effd
https://github.com/dreamcat4/HT1621/commit/1ca058d2d677b130cba23216641073719817effd
If this is not the problem... then maybe the problem is some place elsewhere. For example in the Maple library... so while you check this. Then I will keep looking. Many thanks

Hi, yes that is the library I used, I didn't modify anything so it should work.
What CPU frequency are you using? I use 72MHz, not sure if a different frequency could affect the SPI timings and break communication.
(also make sure there are 5v on the board either by powering it with USB or the ESC connector as the lcd needs 5v to work)
Is the rest of the code running? Have you checked if it isn't stuck somewhere?

Well that took a long time... Other things to do got in the way.
After coming back find out my STLINKv2 dongle stopped working. No longer respond with target. Ordered 2 more from China which doesn't arrive yet.
Had to spend another 1-2 day to figure out how to make debugging work with my other programmer. That nobody else has (TIAO TUMPA v2). Got it working just now! Awesome
So what the place where have got is that I can step over the setup() and can see the point where the backlight is turned on/off. However the backlight... is NOT controlled over the LCD spi bus, right? Which is not the problem. Backlight seems to work just fine no problem.
So then setup() gets into the LCD library to init. And there is this bit to check it can respond valid data. Well I uncommented and enable these 2 lines and step into it in the debugger
https://github.com/dreamcat4/HT1621/blob/master/ht1621.cpp#L27-L28
However data returned back is different than was written. And the check fails. But IDK if that is a valid test. Because in many situation we do not typically need to hear anything back from an LCD any return messages. Because it's purely an output device. So that might just not matter IDK
Anyhow I also check which GPIO pins is configured for the LCD. It is as you published in the public code here for the LCD. Which is this bit:
https://github.com/dreamcat4/Best-Improvement/blob/feature/convert_to_platform_io/src/main.cpp#L83
And like... the library uses standard feature DIGITAL_WRITE to signal the pins for the spi bus. Which I guess we would not normally expect to have any issue.
In my platformio.ini file did uncomment the cpu clock freqency to be 72Mhz too. As you mentioned that could be a problem...
https://github.com/dreamcat4/Best-Improvement/blob/feature/convert_to_platform_io/platformio.ini#L37
However that did not change anything. Issue still occur.
This is where I am now. Maybe I need to bring out the logic analyzer and debug the communication between the MCU and the LCD
Being able to step through in the debuger is helpful. Actually maybe I can stop execution when it's doing the writes to the GPIO pins. And probe them. Without needing to get out the logic analyzer. We chall see! Interesting! ;)

ok so as far as i can see... the wr pin is the clock pin to wite data to the lcd. And it latches in the what is put onto data line, onto the shared bus. And that is the line which is not working here:

so i checked for the continuity etc. for the connection to the logic analyzer was ok. seems was not any bad connection
Looking at the code the wr line is PA15 (pin 38 on the physical package). Is declared in the code as integer enum 25. But maybe then it adds an extra offset to get the real pin number IDK
But this seems like the issue. Because other communication pins looks working. Also this result agrees with the previous testing / checking, whereby the contents stored memory location read back / returned back is different than was written
Will need to dig deeper. And see what stops the pin PA15 from working

ok have some more information, about this issues around driving the LCD here...
what i did was to add some extra lines at the beginning of setup(). to manually step through in the debugger. and set each of the 4 digital pins as OUTPUT mode. And then digitalwrite() each one in turn, first to logic LOW, and then back to logic HIGH
when probing with DMM, what was discovered was each line starts as +5v. because it's being pulled up by the LCD driver IC. then they all (except for PA15, which is broken here) go to 0v (correct), but then setting high it goes back to +3.3v instead of +5v
So this is because the LCD library here initializes the pinMode() to OUTPUT
https://github.com/dreamcat4/HT1621/blob/master/ht1621.cpp#L12-L15
however the correct pinMode setting should be OUTPUT_OPEN_DRAIN. Because that is how to pul low muti voltage (5v <--> 3v3) and is safer way. To avoid uncertain voltage levels.
But that is not the issue, we know (because it already works to drive the LCD). So what about the PA15 pin?
Well measuring this pin, it reads 4.04v constant on the DMM. Which is werid. However that might be the multimeter averaging the value, of some higher frequency. That it cannot see properly. Same for the logic analyzer IDK.
Anyway have just found this, it seems like the reason here:
https://www.stm32duino.com/viewtopic.php?t=70
Because it's shared as a JTAG pin (JTDI). So this is disabling the usage as GPIO. For this SWD debugging. And using SWD for flashing too.
So that also makes me wonder if also other JTAG pins you have used... might also be disabled. Because another thing I noticed was no heating. So maybe for the heater GPIO pin, is also blocked by the JTAG too
What I am not so sure for now... what to do about this. Because on one hand they say to disable + enable programming ports. To release the JTAG only pins. But it might risk loosing SWD capability. Since you did not break out NRST to have the RESET signal to MCU. I think you shuold break out NRST in this case on the programing header. As an optional usage when needed.
The other solution is for me to find some other unused GPIO pin. Cut existing track. Then run a small mod wire(s), from alternate GPIO pins. And that might be better or worse solution IDK
But at least we find some reasons now. And more exactly to recommend for your next PCB revision. If you want the live debugging feature over SWD protocol.

@RandomHacks-Git  ok, the problem is fixed now in the PIO git branch:
https://github.com/dreamcat4/Best-Improvement/commit/f099b5816d17b0e1f0f905189a33b49f524a8e5d
the LCD works now. however i still have to do some more testing on this branch. to make sure everything else works (like the heater GPIO pin for example). and reinstall it back together into the case

I also find out something else. When the LCD is plugged in. Then it creates unwanted interference on the SWD data lines. And the debugger cannot attach. The SWD programmer reports data transmission error, while the reset button is held down.
If i remove the LCD module from the main PCB. Then the SWD connection is successfully established. But not otherwise. This is with both the boot pins set to 0.
So maybe the changing of the boot pin configuration has some connection to the interference coming from the LCD module. Do you have an oscilloscope? Because unfortunately I do not have here. For observing the crosstalk on the data lines etc.
What does this mean? Well it makes this PCB more difficult to debug. Because the SWD connection is unreliable. This could be impoved in a future PCB revision. Along with adding NRST. At least the good news is there is not conflict with the setting for the boot0,1 pins. Which is a good news.
At this point I'm just going stop messing about. And reinstall the PCB back into the machine. To test all functions on the [re]build. Make sure it works

Nice troubleshooting. So in the end did you change PA15 to another GPIO or did you get it working as is?
The only LCD trace that intersects the SWD/SWC traces (on the other layer of the board of course) is the data pin (PB9) and the traces are at 90 degrees to each other creating the smallest intersection area possible so I'm not sure if crosstalk is the issue you are having, but it certainly is possible, I do have an oscilloscope but my time is very very limited right now unfortunately.
I will take note of all the suggestions you made so far so I can take them into consideration if I ever design another stm32 revision 😉

yeah the fix was just to add +1 line in at the beginning of setup() routine. which is call enableDebugPorts(); in the git code commited, already linked above ^^. and now the dispaly works. everything working. no need to use any different GPIO for that one.
and i must say, having just tested the features now. it's my first time ever to get this station working. since before was broken (the blower fan). and it's really impressive. the usability is really awesome. and having the P mode (potentiometer mode) gives a 4th preset. It's so nice to use a real pleasure. Was well worth it, the extra time to get it working. Thank you so much again
So for the interference problem on SWD (coming from the LCD daughter board). IDK what is actually causing this. But maybe a simple solution is to make a jumper bridge on the 2 power pins that supply +5v power to the LCD module (and also the touch too). So that it can be powered off independantly while programming. By removing a jumper link. Just like with these boot pins, by default the jumper is soldered across. To be always on. But then the user can remove it, or install a manual switch to power off the whole LCD module. This then should stop all interference disruption on the SWD programmer lines. If it is not a cross-talk, then maybe it is spikes on the GND line instead IDK
Yes there is no hurry to look into any of those issue. It's mostly to document and keep a record here for later on.  And to make sure that the new code branch for Platform IO is compiling, and working same as original code. Which I have flashed tested now today. And is confirmed to work
Lastly am cleaning up the platformio.ini file a bit. Which includes all of the project settings for building and flashing etc. I upload tonight to the branch

OK great, I am closing this issue. This work is now concluded. And also have other things to do, like use this fabulous hot air station!
However if in the future anytime you ever need to come back here to ask for further clarification about anything specific. Then please don't hesitate. Happy to help if i can remember what was about.
And good luck with your struggles! For changing the MCU etc. and other challenges. I hope you are successful. Certainly I am already recommending this station / mods to all my friends now. Mot that they can get it! hehe. Certainly I feel very fortunate to have gotten this rev1 board while it was available. Thank you so much it's really works so amazingly well. A great pleasure to use this station now

Again back here recording this extra solution, for posterity (to know it, remember it). There is nothing concerning not to worry about it. Is just a small hardware bug in my own unit:
With the final step to put back the last metal cover. Something strange happen, that the unit does not power up correct reliably anymore. Either nothing happen, or the fan comes on. But with no display.
Then I remove the cover, and still not booting. But then I want to check that your mainboard is receiving a clean +15v power rail. Once the front power switch is put ON position.
So jabbing the multimeter probes into +15v + GND (on the ESC board header, where the +15v comes from)... it magically boot and starts working again. I replace the cover, it happen again. Same thing
However in fail state, the +15v rail reads something like +2v only. (or that is the PSU capacitor, which is not fully drained). I am guessing that for some strange reason there is not enough current draw taken by your new mainboard. Is too effecient. Or maybe I somehow degrade or the PSU on my ESC board. From previous hot air rework (to replace the fan driver). Whatever the reason IDK
However simply adding a 120k ohm resistor between +15v rail and GND. On the header cable. Now it boots much more reliably. Every time. So I am also wondering now... if that can help too... for the previous issue I encounter here. That the SWD link is disrupted when the LCD is plugged in. Because of a junk noise / data returned back while the MCU is held in reset state.
I do not want to go back now and try this. Because am finished for the time being. However it's just simply noted to remember for later. Next time. Since to have the LCD plugged in is the fully assembled state. And makes future debugging much easier. Not to have to dismantle everything. And be blind without the display connected.
Of maybe some other simple type of a filter caps etc. If not on the +15v power rail. Then instead on the +5v rail, or 3v3. Or closer to those SWD programmer lines IDK. Something to look at for next time


Resolve Issue #809

#809 brought to my attention that I had mistakenly pushed the same code to two games (pushed 91_train to 91_train and 92_trap), this PR removes the rust implementation of 92_trap (which was really just 91_train), I'll probably contribute an actual implementation of 92_trap soon.
Sorry about this, but glad it's fixed now :)

No worries, I was gonna do it later today so I haven't started yet, can you @ mention me in the pr so I can update #595 when you get it done?

Oops, I created conflicts. My bad!

no worries, given that the PR that created the conflict also fixes this issue, I'd say it's safe to just close this PR

No worries, I was gonna do it later today so I haven't started yet, can you @ mention me in the pr so I can update #595 when you get it done?

Sure thing, I will do that in the future. The 92 Trap PR is complete


Improve token generation using Multicall, Make it typescript safe, enhance logic

This PR enhances a few aspects of the generation of the lists
Issues with the list generation
Yesterday, we had some issues with the list generated from the CSV files.
This issues where derived by casting to TokenInfo the information from the CSV.
This has 2 important problems:

The CSV might omit some values. The way it was defined the CSV can omit things like the symbols, or the decimals, or the images

TokenInfo has most of the fields as required, so the types won't make you handle the undefined or empty string case.
The CSV is a text file, so it reads all the fields as strings, but then we were casting it to TokenInfo so the typechecker was not realising the chainId and the decimals where being passed as strings when they should be numbers.

This PR acknowledge this, so it declares 2 new types, one is for the expected type of the row in the CSV, and another is to define a partial token info, which acknowledges the possibility we haven't found all the information for a token onchain. This way, we can handle the cases, and get typescript checks to ensure the list will be well-formed.
Multi-call
Additionally, there was the issue of performance and gas consumption. Before this PR we would get all the erc20 information from the additional tokens, just to fill any missing data. Each token would make 3 RPC call (one for symbol, one for name, one for decimals).
This PR makes use of multi-call and will send 3 RPC calls in parallel for all tokens.
Add missing images
Yesterday I added, as a shortcut some images in the resulting JSON list directly.
Ideally, I should have added that in the CSV and the re-generated the token list using the script. I didn't do that because the script was broken as described above and just took a shortcut.
See this PR:
https://github.com/cowprotocol/token-lists/pull/401
In this PR I add the images into the CSV, this way I can make a check that the script will generate the same token list (I verified that the JSON has no changes)
Test
Run the code, make sure the token lists don't change after running the script
yarn coingeckoToArbitrumOneList

@anxolin you still have this one pending


Any plan for StyleLint?

I have a new parser for PostCSS/StyleLint, postcss-html.
features about vue:

Compatible with vue component
Support automatically fixes of StyleLint.
Support syntax definded in <style lang="*">
Syntax detection by file extensions for non vue component file.

Usage:
stylelint "**/*.{vue,html,css,sss,less,scss,sass}" --custom-syntax postcss-html

Related:

#154
vuejs/vue-loader#303
stylelint/stylelint#2596

/CC @dan-gamble

Stylelint is used by Facebook, Wikipedia and GitHub.
create-react-app will support it in 2.0.
Right now it is the most popular CSS linter.

Stylelint is great! I've been adding it to all my frontend projects. I'd love to see support out of the box in the template.

A temporary solution is separate your html, (s)css and js files to let PostCSS's plugin stylelint to process.
An elegant way to separate these file is using vue-separate-files-loader.

A temporary solution is separate your html, (s)css and js files to let PostCSS's plugin stylelint to process.

I used another solution, postcss-html for stylelint CLI
stylelint "**/*.{vue,htm,html,css,sss,less,scss,sass}" --custom-syntax postcss-html

@gucong3000 it‘s nice to deal with it.


[NeuralChat] Add ROME implementation and example

Type of Change
Add ROME implementation and example.
Description
detail description
JIRA ticket: xxx
Expected Behavior & Potential Risk
pass local test
How has this PR been tested?
follow readme
Dependency Change?
no library dependency introduced or removed

Is it convenient to add a UT in the nightly UT test about this tool?

Is it convenient to add a UT in the nightly UT test about this tool?

added nightly UT.


Initial guess

Hi, is there a way to provide an initial guess or starting point for the exploration? Should I just build a custom OptimizationProblem object with an observation already filled in? I tried doing this like the example using OptimizationProblem.from_json, but it seems that it won't take a dictionary, only strings or other objects.

Hi, You can use
optimization_problem = OptimizationProblem.from_list([
    {
        "name": "param1",
        "category": "category",
        "search_space": {"values": ["a", "b"]}
    },
    {
        "name": "param1",
        "category": "normal",
        "search_space": {"values": [1, 2]}
    }
])

optimization_problem.add_observations_from_list(
    [
        {
            "loss": 0.5,
            "parameters": {"param1": "a", "param2": 1.5}
        },
        {
            "loss": 0.7,
            "parameters": {"param1": "a", "param2": 1.8}
        },
        {
            "loss": 0.1,
            "parameters": {"param1": "b", "param2": 1.1}
        },
]

Ah, I think I see my issue. I was trying to use minimize, but it seems like that function only accepts a list, and throws an error (UnboundLocalError: local variable 'optimization_problem' referenced before assignment) if it's passed in anything else. If I implement minimize myself it works fine. All it takes is copying the code from minimize and replacing all occurrences of optimization_problem_parameters with optimization_problem. It seems like this was the original intention for minimize?

You are right, It is clarified now thanks!


Longest decreasing subsequence

[X] Read the contribution guidelines
[X] Added unit tests (or unit tests have already been added)
[X] Updated the Contents

@alxmjo If you would be willing to look over these I implemented all of the changes you requested.

@alxmjo Yes, the include guards are required in all header files. As for the "show state" functionality, it's only useful in algorithms like sorting where it is insightful to see what's going on as the algorithm works.

Noted. Thanks Faheel.
Cole: I don't have any more comments for this PR (besides the trailing semicolon). I'll leave it up to Faheel to offer and more guidance and/or merge.

@alxmjo Ok! Fixed the trailing semi-colon. The show_state in this algorithms shows the longest subsequence, whereas normally just the length is returned

Thanks, @ColeSeverson. One other thing that's probably worth changing (sorry to keep throwing these at you!) is to set to_show_state to default to false. Users probably don't want to see the intermediate states of this algorithm unless they specifically request them. Beyond that, I'll leave this up to Faheel to merge.

@alxmjo No problem! Fixed the last couple things

@alxmjo Ok! That should do it for the std::

@ColeSeverson Still one more to resolve. See my comment on your test file.

@alxmjo ok no problem, I replaced the removed the std:: calls from the test file and used "using std::vector" instead

@ColeSeverson Did you push that commit? Not seeing it.

@alxmjo The changes to the test file were included in the previous commit.

@ColeSeverson Hmm. Sorry if it's my mistake, but I'm definitely still seeing the same version of the .cpp file: https://github.com/faheel/Algos/pull/199/files#diff-41e6ffc70719257aa7824c4caf45d373.
#include "third_party/catch.hpp"
#include "include/algorithms/dynamic_programming/longest_decreasing_subsequence.hpp"

TEST_CASE("Base cases", "[longest_decreasing_subsequence]") {
	REQUIRE(longest_decreasing_subsequence(std::vector<int>({}) == 0);
	REQUIRE(longest_decreasing_subsequence(std::vector<int>({1}) == 1);
}

TEST_CASE("Test cases", "[longest_decreasing_subsequence]") {
	REQUIRE(longest_decreasing_subsequence(std::vector<int>({1,2,3,4,0}) == 2);
	REQUIRE(longest_decreasing_subsequence(std::vector<int>({10,12,11,9,8,5,6,2}) == 7);
	REQUIRE(longest_decreasing_subsequence(std::vector<int>({1,2,3,4,5,6,7,8,9,10}) == 1);
}

@alxmjo Huh this is odd, I have it changed locally but I cant seem to push it. Ill message you if I can get it to work

Sounds good. Let me know if you need a hand.
On Thu, Oct 11, 2018, 21:02 Cole Severson<EMAIL_ADDRESS>wrote:

@alxmjo https://github.com/alxmjo Huh this is odd, I have it changed
locally but I cant seem to push it. Ill message you if I can get it to work
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/faheel/Algos/pull/199#issuecomment-429197505, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABlFKgzcNcnPFnD-JXV3AV4gDa35pBrhks5ukBRNgaJpZM4WgCJW
.

@alxmjo Ok I added another test case so that git would allow me to commit it again. This one should be clean of std::vectors

This looks good to me, Cole. Thank you. I'll leave it up to @Faheel to do his review and merge.

@faheel any issues?

@ColeSeverson Thanks a lot for contributing! I'm sorry that it took so long for me to approve and merge this PR, so thank you for your patience too :slightly_smiling_face:


Missing License

Would like to request adding a license to the project.

Hi @richardschembri. I've added a licence to the project.
Thank you!

Thanks, much appreciated :)


Fixed typo

Pull Request Check List
This is just a reminder about the most common mistakes. Please make sure that you tick all appropriate boxes.  But please read our contribution guide at least once, it will save you unnecessary review cycles!

[ ] Added tests for changed code.
[ ] Updated documentation for changed code.

Note: If your Pull Request introduces a new feature or changes the current behavior, it should be based
on the develop branch. If it's a bug fix or only a documentation update, it should be based on the master branch.
If you have any questions to any of the points above, just submit and ask!  This checklist is here to help you, not to deter you from contributing!

Thanks!

@sdispater Thank you for the most stunningly beautiful CLI interfaces any modern python lib has to offer!


Bulk update to C++-17

The last attempt to split out the commits didn't work so here is a bulk update to C++-17 for discussion.
The big changes are:
Putting unicode string into the icu namespace
auto_ptr->unique_ptr
added a virtual destructor to a base class that needed to (and fixed all the bugs that resulted)
a bunch of things like char is a signed value, in code strings are const, etc.
tempfile creation updated
move to standard map and set in stl
A really insidious bug in the sax interface where the wrong type was used
plus over all cleaning pass

Tested these changes on RHEL 7.7 machine with compile option -std=c++11.  c++14/c++17 were not compatible with the version of Xerces-C pulled from the RHEL 7 repo.


Adds noTitle option to RelativeTime component

Blocked until a new release of https://github.com/github/relative-time-element ships and is updated in primer/react.

Closes https://github.com/github/accessibility-audits/issues/5633

Changelog

New

Changed

Removed

Rollout strategy

[ ] Patch release
[x] Minor release
[ ] Major release; if selected, include a written rollout or migration plan
[ ] None; if selected, include a brief description as to why

Testing & Reviewing

Merge checklist

[x] Added/updated tests
[x] Added/updated documentation
[x] Added/updated previews (Storybook)
[x] Changes are SSR compatible
[x] Tested in Chrome
[x] Tested in Firefox
[x] Tested in Safari
[x] Tested in Edge
[x] (GitHub staff only) Integration tests pass at github/github (Learn more about how to run integration tests)

Integration failures are unrelated to this PR!

Hi!
Can i request additional context, what does passing no-title down do? When is it recommended to use + when is it not recommended to use?

Would it be preferable to always have the title not be present, at least from the Primer React side? Internally we could set noTitle on the relative time element but we wouldn't expose it as a prop to consumers to toggle.
Just wanted to ask to see if this would be helpful or if not because of what you shared about usage at GitHub and how there isn't a good alternative yet when the title is not displayed 👀

Would it be preferable to always have the title not be present, at least from the Primer React side? Internally we could set noTitle on the relative time element but we wouldn't expose it as a prop to consumers to toggle.

Yes, it would be preferable to never have a title attribute! I added a story that shows how we can instead use a Tooltip on interactive elements, but that doesn't solve the case of non-interactive elements :/ If you think it's ok I am totally fine removing the title attribute altogether, but I think that may ruffle some feathers and we'd would probably require user testing first 😅

If it helps, I have a PR for updated guidance in the works that I will merge after this one is merged :)

Yes, this was very helpful!
Please correct me if I understood this incorrectly:

For visual users, the date is presented as "3 days ago" and then they can hover for exact date + time
For screen reader users, the date is also presented as "3 days ago", but there is no way to know exact date + time because title is ignored.

(this is where I'm probably understanding incorrectly)
To make both experiences similar, we need to replace title with an accessible element, like a tooltip. By removing title without replacing it with tooltip, we do make the experience the same, but don't we lose the detailed information about data and time?

Ideally it'd be default behavior, but we'd need a larger conversation with stakeholders and design to come up with an accessible solution (we've attempted this in Office Hours, but there is nothing straightforward that we can do other than this without extensive testing).

That's fair! I feel a little worried about noTitle because I don't know how it or where will be used in the product. Can you share a little more on that.
How do you feel about primer components for RelativeTime (both PRC and PVC) using a tooltip instead of a title? It would lead to some inconsistency in the short term (between primer vs non-primer relative time), but hopefully will set the direction towards accessible + consistent

You are mostly correct with how you're understanding it! The other user we're excluding is keyboard users -- even if a user can navigate to the element because it's focusable, like a link, the title attribute does not display for them.

but don't we lose the detailed information about data and time?

No, if we pass in the full date and time as the tooltip (check out the story Link with Tooltip) that shows the full date in the tooltip, but the shortened version as the main text.

I feel a little worried about noTitle because I don't know how it or where will be used in the product. Can you share a little more on that.

Sure! We can think of this as a "baby step" to a fully accessible solution. Since we don't have one right now, this is better than what currently exists, but still not fully ideal. One example of where this can be used in the product is on PRs, where the timestamp acts as a link to that comment. We can use noTitle to not render a title attribute, and instead replace it with a Tooltip with the full time as it is in the example story.
I am also thinking that if audit issues start coming in, similar to the one linked in the PR, it gives teams a way to fix the audit issue with minimal impact or needing to reassign the issue to Primer -- they have a few options of how to address it. They can do one of the following:

Pass in noTitle so they don't render a title (and we can let the teams decide if they want to replace it or go without it)
For interactive elements, pass in noTitle and pass in the full date/time in a Tooltip
For non-interactive elements, pass in noTitle and write as much of the full date/time out as possible

How do you feel about primer components for RelativeTime (both PRC and PVC) using a tooltip internally instead of expecting it to be added in the product?

We considered this! The tricky part is that not all RelativeTime elements are interactive. Some are static text, which we can't render a Tooltip on in an accessible way. We considered having two components, RelativeTime (as-is) and RelativeTimeWithTooltip, but right now consumers wrap the RelativeTime component in a <Link> tag, so it'd be hard to determine in the component what it's parent is and whether or not it should render a Tooltip. Also, consumers may not know the difference between the two. But if you think otherwise, we can explore it.

Ah, I seeee! Thanks you going into detail, now it's very clear to me.

The tricky part is that not all RelativeTime elements are interactive.

I completely missed this detail

Summarising for myself first:
Current scenario:

RelativeTime renders an inline text element (usually short text like "3 days ago")
We add a title attribute to the element which has the full datetime, but is only available to visual users, not to screen reader users

Ideal scenario:

Case 1: If RelativeTime (inline text element) is wrapped in an interactive element like Link, the parent element can receive focus and we can add a Tooltip on the parent element with full datetime. To make sure there isn't also a redundant browser tooltip, we need to remove title attribute
Case 2: If RelativeTime is standing on it's own, there is no way to show full datetime consistently between visual users and screen reader users. We need to modify the text to show more details by default. We could keep the title attribute, but it's better to nudge developers to keep the experience consistent

@siddharthkp Everything you said looks good, one slight modification:
"We add a title attribute to the element which has the full datetime, but is only available to visual users, not to screen reader users or keyboard users"
And regarding:

We could keep the title attribute, but it's better to nudge developers to keep the experience consistent

Correct! Eventually we hope to have a better solution, but this is just one small step to getting there :)

We can think of this as a "baby step" to a fully accessible solution. Since we don't have one right now, this is better than what currently exists, but still not fully ideal.
I am also thinking that if audit issues start coming in, similar to the one linked in the PR, it gives teams a way to fix the audit issue with minimal impact

Very fair, happy to merge this as a temporary "unblocker" for teams. I'd nudge you to follow up with a discussion post to find a long term fix? (I call it temporary, but once it's in dotcom, nothing is temporary as we would need to keep it until it's replaced)

@siddharthkp Thank you! That totally makes sense. That plan would also need to include a deprecation plan for relative-time-element since it's reliant on that... I can follow up with a Discussion post with the current findings and research we've done :)

@siddharthkp posted! https://github.com/primer/react/discussions/4645


Can't upgrade (or install?) Phabricator on VM

Receive the following at the very end of the install script (and also whenever trying to run the upgrade script):
0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
Executing if [ ! -d phabricator ]; then git clone https://github.com/GoogleCloudPlatform/compute-phabricator.git; else cd phabricator; git fetch; git rebase origin/master; fi...
fatal: destination path 'compute-phabricator' already exists and is not an empty directory.

Hmm -- it seems like the script is expecting a directory named phabricator, but the top-level directory on the VM is actually compute-phabricator. There's a directory called phabricator inside vm/third_party -- maybe it's looking for that?

Renamed the directory in the VM to simply phabricator. Seems to be getting stuck on the following now:
/home/dillongrove/phabricator/vm/upgrade.sh: line 34: pushd: phabricator: No such file or directory

Assuming again that it's looking for the one in third_party?

Changing the vm/upgrade.sh script to reference third_party/phabricator seems to allow me to move forward.

Nevermind the error in the previous comment. I think I broke something trying to debug :)
I tried with a fresh cloud project, and it looks like the following steps result in success:

Run install. It will fail and exit when trying to run the VMs install script.
./ssh into the VM
Run `mv ~/compute-phabricator ~/phabricator
Exit ssh and re-run install


869 Fix for block extra_js running twice

Undo block extra_js removal from base.html.
Moved block extra_js out of main block in genericresource.html

As discussed in #869

Can one of the admins verify this patch?

+1


SwiftUI previews with multiple modules

Hello,
I've been facing problems with the SwiftUI preview, I have an app that runs clean architecture in multiple modules, SwiftUI preview doesn't work properly running the app scheme, so I had to run specifically the UI module, this works properly in most of the cases but sometimes injecting with @LazyInjected doesn't solve the issue and get the error  resetAndTriggerFatalError("\(T.self) was not registered", #file, #line), I tried changing the build configuration to release for that module but for some reason the preview didn't work at all.
    public func promised<T>(key: StaticString = #function) -> Factory<T?>  {
        Factory<T?>(self, key: key) {
            #if DEBUG
            if self.manager.promiseTriggersError {
                resetAndTriggerFatalError("\(T.self) was not registered", #file, #line)
            } else {
                return nil
            }
            #else
            nil
            #endif
        }
    }

Would probably need a minimum viable project to try and diagnose this.

I'll prepare a quick demo.

Demo:
This demo is a project using clean architecture with multiple modules, where each layer (Data, Domain, and Presentation) is separated into distinct modules. In this setup, the Presentation module is separated into a package, and the App module is responsible for injecting dependencies into the other modules.
https://github.com/callo90/factory-demo
Problem:
The error arises because the promised<T>(key: StaticString = #function) -> Factory<T?> doesn’t account for whether it's running the SwiftUI preview mode or not, which causes issues when injecting dependencies.
Fix:
I forked the project and fixed the error by adding a validation for preview mode with FactoryContext.current.isPreview. This ensures that dependencies are injected correctly when running previews.
https://github.com/callo90/factory
https://github.com/hmlongco/Factory/compare/main...callo90:Factory:main?expand=1
Screenshots:
Here are some screenshots that highlight the issue:

Let me know if you need anything else!

Hey @hmlongco did you have the chance to review this?

Preview Promise should be fixed in 2.4.0
private var _promiseTriggersError: Bool = FactoryContext.current.isDebug && !FactoryContext.current.isPreview

Great! Left this PR with a similar approach

Hello
I also experienced the same issue, and after testing the fix in the version shared by @callo90, it really seems to work. I want to thank you all for taking the time to address this issue. I’ll be testing version 2.4.0 to confirm if it resolves my problem completely.
Thanks again for your effort and support!


Need access to status updates while awaiting the completion of a long running request

https://github.com/Azure/azure-sdk-for-net/blob/382f6a568d67f1995f4db1e998ed3dd1ab2d9eb0/src/SdkCommon/ClientRuntime.Azure/ClientRuntime.Azure/AzureClientExtensions.cs#L71
This method GetLongRunningOperationResultAsync() abstracts away all the gory details of handling long running requests. That's a great idea!
Unfortunately, it also abstracts away any possibility of watching the progress of those requests. According to documentation status field of the response can contain arbitrary values for non-terminal statuses. For example, the operation of restoring a SQL Database from a dacpac provides the names of stages of the process.
The GetLongRunningOperationResultAsync() hides all those in-progess status messages from the caller and only returns once the poll request produces one of the terminal statuses of Succeeded, Failed or Canceled.
Would it be possible to pass some kind of callback as an additional parameter that would be called when the polling code gets a status update? Also, would you mind reporting percentComplete as well?

Closing this as this is supported in our Track 2 library.


Why is the MaxNumberOfEventsPerBatchRequest is 50?

If I change that value and build the pio, will that work?, I saw the code, the val is being compared to the current length of events at the time of a new batch request, i do not see any other dependency with that val parameter, will this work if i change the value to a higher number?

Please bring this to<EMAIL_ADDRESS>(http://predictionio.incubator.apache.org/support/). GitHub issues is no longer supported after ASF migration and will eventually shutdown. Thanks!


Still in Preview?

Hi,
is this feature/setting really still in preview, as mentioned in the heading? I can't find any other source that is confirming this.
Thanks

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

ID: 8d2d7bd8-ecfb-091f-af61-d5c53613bc11
Version Independent ID: 3820216a-f1f2-b52a-6f1e-9e3fcfbb039c
Content: Prevent object replication across Azure Active Directory tenants (preview) - Azure Storage
Content Source: articles/storage/blobs/object-replication-prevent-cross-tenant-policies.md
Service: storage
Sub-service: blobs
GitHub Login: @tamram
Microsoft Alias: tamram

@sebhe I looked into this and can verify this is still in preview. When a feature is made GA we update the documentation to reflect this.


CloudWatcher Failing To Start

Hi,
I've been testing cloudwatcher. I updated the sample_configuration.yaml to a custom log_stream_name
However I get the error messages below:

[ERROR] [1543682968.675952432]: [AWSClient] HTTP response code: 400
Exception name: ResourceAlreadyExistsException
Error message: The specified log group already exists
5 response headers:
connection : close
content-length : 94
content-type : application/x-amz-json-1.1
date : Sat, 01 Dec 2018 16:49:28 GMT
x-amzn-requestid : 116c39c3-f589-11e8-be76-d3e7ff879f8f
[ERROR] [1543682968.676457696]: [CreateLogGroup] Failed to create Log Group :robot_application_name due to: The specified log group already exists, with error code: 135
[ERROR] [1543682968.790863450]: [AWSClient] HTTP response code: 400
Exception name: ResourceAlreadyExistsException
Error message: The specified log stream already exists
5 response headers:
connection : close
content-length : 95
content-type : application/x-amz-json-1.1
date : Sat, 01 Dec 2018 16:49:27 GMT
x-amzn-requestid : 117c8dd5-f589-11e8-bd16-65b3e1494de1
[ERROR] [1543682968.791192148]: [CreateLogStream] Failed to create Log Stream :mxnet_kobuki_robot_log_stream in Log Group :robot_application_name due to: The specified log stream already exists, with error code: 135

According to the config file - it will try to create the log stream if it doesn't exist. Although the error messages seem to indicate otherwise.
How can I resolve this? And where should I expect the log stream to appear - I'm assuming eu-west-2 (I updated this config to reflect this.
Thanks and Regards
Mark

Hi Mark,
The error messages seem to indicate that the log stream already exists, rather than they don't exist.
Can you confirm that you don't already see in your CloudWatch Logs the Log Group "robot_application_name" and under it the Log Stream "device_name"?
Thanks

My gut feeling here is that these error messages being printed are falsely indicating that there's an error.

Hi mm318,
Yes agreed that looks like it's the case. I left it up running and sent in a few messages to existing and new log groups and saw the messages come up.
Will close
Cheers
Mark

We will fix these false error messages. Thank you!

https://github.com/aws-robotics/cloudwatch-common/pull/1 has been merged
resolving


Share the rounds before sumcheck/folding between the UltraHonk and Folding Verifier

This could also include the recursive verifiers.

Closed by OINK


Sandbox Tester creation with Fastlane errors out with an unexpected Response  error.

New Issue Checklist

[X] Updated fastlane to the latest version
[X] I read the Contribution Guidelines
[X] I read docs.fastlane.tools
[X] I searched for existing GitHub issues

Issue Description

We currently have a process within which we have sandbox testers created. Recently ever since the rollout of the new 2FA from Apple it seems like the process of creating sandbox testers has been flaky and now completely erroring out. I am still using the code snippet on the Shapeship readme
Spaceship::Tunes::SandboxTester.create!(
      first_name: "abc",
      last_name: "abc",
      email: "email",
      password: "password",
    )

As well as using the 8hr token thats generated with Spaceship (tried using api key but i think that the API keys do not have access to /Iris/* endpoints.
The Error that i see  is
Spaceship::UnexpectedResponse: {"data"=>nil, "messages"=>{"warn"=>nil, "error"=>["Not Found"], "info"=>nil}, "statusCode"=>"ERROR"}
I tried this in different environments and still ended up with the same issue.
Command executed

Spaceship::Tunes::SandboxTester.create!(
      first_name: "abc",
      last_name: "abc",
      email: "email",
      password: "password",
    )

Complete output when running fastlane, including the stack trace and command used

	/Users/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.132.0/spaceship/lib/spaceship/client.rb:709:in `parse_response'
	/Users/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.132.0/spaceship/lib/spaceship/tunes/tunes_client.rb:1458:in `create_sandbox_tester!'
	/Users/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.132.0/spaceship/lib/spaceship/tunes/sandbox_tester.rb:46:in `create!'
	/Users/ruby/sandbox_tester.rb:35:in `create_sandbox_tester'
	/Users/ruby/sandbox_tester.rb:15:in `initialize'
	/Users/ruby/ios_users.rb:66:in `new'
	/Users/ruby/ios_users.rb:66:in `block in create_sandbox_accounts'
	/Users/ruby/ios_users.rb:60:in `times'
	/Users/ruby/ios_users.rb:60:in `create_sandbox_accounts'
	/Users/ruby/ios_users.rb:141:in `lambda_handler'
	/Users/ruby/ios_users.rb:146:in `<top (required)>'

Environment

 [REPLACE THIS WITH YOUR INFORMATION]

The ASC API keys only have access to the "official" endpoints. Is it working with an Apple ID and 2FA enabled?

Hi @max-ott. Thank you for your response. It doesn't seem to work with the 2FA enabled. It's kind of strange in that it was working for a while and somewhere around February it just stopped. At that point, i tried regenerating the session_token, which works in getting all of the sandbox users but fails during creation of sandbox users.
https://github.com/fastlane/fastlane/blob/6702e2eeef1f383b3627b940f6e6c76d4ebc1551/spaceship/lib/spaceship/tunes/tunes_client.rb#L1450
I did a rough debug session and realized that it  was the request being sent over to the unofficial iris api. So I tried a few things:

use spaceship playground to try and generate the creation of users.
change the data and allow for the defaults to be passed in here:

https://github.com/fastlane/fastlane/blob/6702e2eeef1f383b3627b940f6e6c76d4ebc1551/spaceship/lib/spaceship/tunes/sandbox_tester.rb#L45
Still ended up with the same traceback shown above.

I don't think this has anything to do with the 2FA change. Maybe they changed something on their end. It also seems that you are still using the old Spaceship::Tunes instead of Spaceship::ConnectAPI. Can you check if we already have actions over there?

yeah i did. I think because connectAPI focuses on the API's provided by apple, it is not there. Will post stack trace below:
	/Users/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.177.0/spaceship/lib/spaceship/connect_api/api_client.rb:199:in `handle_response'
	/Users/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.177.0/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
	/Users/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.177.0/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:1133:in `get_sandbox_testers'
	/Users/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/forwardable-1.3.2/lib/forwardable.rb:238:in `get_sandbox_testers'
	/Users/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.177.0/spaceship/lib/spaceship/connect_api/models/sandbox_tester.rb:41:in `all'
	/Users/tools/test-account-creation/ruby/ios_users.rb:140:in `lambda_handler'
	/Users/tools/test-account-creation/ruby/ios_users.rb:146:in `<top (required)>'

Seems like it's unable to find the resource.

@cris-mwaura I think you are mixing up things. ConnectAPI does not mean it uses the official API. Josh introduced ConnectAPI when Apple changed most parts of App Store Connect. It tries to use as much of the "official" API as possible, but as you have noticed Apple actually has 2 different APIs. Their "internal" one using /iris and the public one. Fastlane uses both to provide the broadest possible feature set.
I just tried out response = Spaceship::ConnectAPI.get_sandbox_testers and get all Sandbox testers, so the "new" code definitely works, e.g. here: https://github.com/fastlane/fastlane/blob/2c34e6573dcf0014670af3a554fa92a9ad2566b7/spaceship/lib/spaceship/connect_api/tunes/tunes.rb#L1131
The post_sandbox_testers should be the method to create new testers. I just tested it and it worked:
attributes = {}
# Then go through all attributes like this
attributes["email"] =<EMAIL_ADDRESS>...
Spaceship::ConnectAPI.post_sandbox_tester(attributes: attributes)

You can find all attributes here: https://github.com/fastlane/fastlane/blob/2bdb19d08db3964ddf6b20c830c63eb069b5a1ed/spaceship/lib/spaceship/connect_api/models/sandbox_tester.rb#L47

Hi Max,
I tried this with post_sandbox_tester and it seems like it's still not working on my end. The code i added was Spaceship::ConnectAPI.post_sandbox_tester(attributes: attributes) and within the attributes i added all the params.
Uncaught exception: The URL path is not valid - The resource 'sandboxTesters' does not exist
	/Users/cris/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.177.0/spaceship/lib/spaceship/connect_api/api_client.rb:199:in `handle_response'
	/Users/cris/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.177.0/spaceship/lib/spaceship/connect_api/api_client.rb:124:in `post'
	/Users/cris/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.177.0/spaceship/lib/spaceship/connect_api/tunes/tunes.rb:1144:in `post_sandbox_tester'
	/Users/cris/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/forwardable-1.3.2/lib/forwardable.rb:238:in `post_sandbox_tester'
	/Users/cris/HeadspaceProjects/tools/test-account-creation/ruby/sandbox_tester.rb:46:in `create_sandbox_tester'
	/Users/cris/HeadspaceProjects/tools/test-account-creation/ruby/sandbox_tester.rb:15:in `initialize'
	/Users/cris/HeadspaceProjects/tools/test-account-creation/ruby/ios_users.rb:66:in `new'
	/Users/cris/HeadspaceProjects/tools/test-account-creation/ruby/ios_users.rb:66:in `block in create_sandbox_accounts'
	/Users/cris/HeadspaceProjects/tools/test-account-creation/ruby/ios_users.rb:60:in `times'
	/Users/cris/HeadspaceProjects/tools/test-account-creation/ruby/ios_users.rb:60:in `create_sandbox_accounts'
	/Users/cris/HeadspaceProjects/tools/test-account-creation/ruby/ios_users.rb:144:in `lambda_handler'
	/Users/cris/HeadspaceProjects/tools/test-account-creation/ruby/ios_users.rb:147:in `<top (required)>'

Process finished with exit code 1```

This is done after both generating the token with connectAPI and a P8 key as well as after i also did a spaceship login.

Can we perhaps reopen this issue pls

I'm not able to repro the steps. What are your attributes? How are you creating them? What is the role of your Apple ID? I don't think the official App Store Connect API supports this feature, therefore you get the problem. How do you login?


bugtool: dump output of routing tables that have rules to prevent proxy looping

Example output from running bugtool
$ cat ip--4-route-show-table-2005.md
# ip -4 route show table 2005

default via <IP_ADDRESS> dev cilium_host
<IP_ADDRESS> dev cilium_host scope link

$ cat ip--6-route-show-table-2005.md
# ip -6 route show table 2005

fe80::d829:f8ff:febc:fcdc dev cilium_host metric 1024 pref medium
default via fe80::d829:f8ff:febc:fcdc dev cilium_host metric 1024 pref medium

Fixes: #5828
Signed-off by: Ian Vernon<EMAIL_ADDRESS>

This change is

test-me-please

test-me-please

Tests failed:
22:49:54 K8sServicesTest
22:49:54 /home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:351
22:49:54   Checks ClusterIP Connectivity
22:49:54   /home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:351
22:49:54     Checks service on same node [AfterEach]
22:49:54     /home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:383
22:49:54
22:49:54     Found a 'JoinEP: ' in Cilium Logs
22:49:54
22:49:54     /home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:474

Investigating.

test-me-please


5.5.4-php7/Dockerfile

You created the php7 image from dnhsoft/shopware-base:5.2.x instead of dnhsoft/shopware-base:5.2.x-php7

It is fixed now


Fixes #38. Add a description field to the UI for tasksi

Looking very good. Could you also display the input descriptions on the "Setup and run" dialog on this branch? Perhaps using this style
http://getbootstrap.com/css/#forms-help-text
Displaying the type:format of each input would be nice too.
The analysis description on the main panel could possibly also use this style but not sure how it would look - use your best judgment.
Couple more things we could do:

Hovering over inputs/outputs/task in the workflow editor could show description text if there is any.
The "Setup and run" dialog should contain all help text - including repeating the task description near the top and enumerating outputs with their descriptions (and type/format) somewhere in the dialog.

@jeffbaumes I added the task descriptions and input descriptions and types to the setup and run dialog.

This is looking very nice. Two more things:

Since Romanesco does auto-conversion between formats, the actual input format is an implementation detail that does not need to be exposed in the Setup and run dialog, so I think it should be changed to just include the type.
Include a list of output names, types (again no formats), and descriptions under the main task description in the Setup and run dialog.

With these two changes I think this branch will be ready. I'll make a separate issue for exposing descriptions in the workflow editor.

@jeffbaumes ptal

Looks great! After debug statement is removed LGTM.


[Coverity CID :188743]Program hangs in /tests/posix/common/src/posix_rwlock.c

Static code scan issues seen in File: /tests/posix/common/src/posix_rwlock.c
Category: Program hangs
Function: test_posix_rw_lock
Component: Tests
CID: 188743
Please fix or provide comments to square it off in coverity in the link: https://scan9.coverity.com/reports.htm#v32951/p12996

False positive, test requires to sleep while holding lock, to verify other threads cannot acquire lock. This is not a mistake, this is intended implementation for the test.


Give a stack trace

We can use GHC.Stack to get the stack trace of where the API is called, and dump the stack into the item. Should make looking at items a bit easier.

Hey @joneshf ! Thanks for working on the library, really-really helpful! 👍
Do you think you'll have the opportunity to work on this issue any time soon?

Sure! I've been wanting this more and more. I'll see what I can do in the next few days.

Sounds amazing! Really interested to see the code -- GHC and stack traces is still kind of an uncharted territory to me :/

Sorry, forgot there were holidays coming up. Will be a bit longer yet.

Oh, no worries :) Whenever you have the opportunity.


Add ElementHandle.WaitForSelectorAsync()

Hello. Could we add WaitForSelectorAsync for ElementHandle
There are few reasons for such functionality

Performance. There is no reason to query whole document if we can query only subset
And when you have multiple similar nodes and you want to monitor one certain node, and there is no way to do this.

Currently I have second issue.
And here is how I solve it with extension method. I used reflection because WaitTask is internal

public static Task<ElementHandle> WaitForSelectorAsync(this ElementHandle element, string selector, WaitForSelectorOptions options = null)
            => WaitForSelectorOrXPathAsync(element, selector, false, options);
public static Task<ElementHandle> WaitForXPathAsync(this ElementHandle element, string xpath, WaitForSelectorOptions options = null)
            => WaitForSelectorOrXPathAsync(element, xpath, true, options);

public static async Task<ElementHandle> WaitForSelectorOrXPathAsync(this ElementHandle element, string selectorOrXPath, bool isXPath, WaitForSelectorOptions options = null)
        {
            options = options ?? new WaitForSelectorOptions();
            const string predicate = @"
              function predicate(rootElement,selectorOrXPath, isXPath, waitForVisible, waitForHidden) {
                const node = isXPath
                  ? rootElement.evaluate(selectorOrXPath, rootElement, null, XPathResult.FIRST_ORDERED_NODE_TYPE, null).singleNodeValue
                  : rootElement.querySelector(selectorOrXPath);
                if (!node)
                  return waitForHidden;
                if (!waitForVisible && !waitForHidden)
                  return node;
                const element = node.nodeType === Node.TEXT_NODE ? node.parentElement : node;
                const style = window.getComputedStyle(element);
                const isVisible = style && style.visibility !== 'hidden' && hasVisibleBoundingBox();
                const success = (waitForVisible === isVisible || waitForHidden === !isVisible);
                return success ? node : null;
                function hasVisibleBoundingBox() {
                  const rect = element.getBoundingClientRect();
                  return !!(rect.top || rect.bottom || rect.width || rect.height);
                }
              }";
            var polling = options.Visible || options.Hidden ? WaitForFunctionPollingOption.Raf : WaitForFunctionPollingOption.Mutation;
            var type = typeof(WaitForFunctionPollingOption).Assembly.GetType("PuppeteerSharp.WaitTask");
            var consturtor= type.GetConstructors(BindingFlags.Instance | BindingFlags.NonPublic)[0];
           var waitTask = consturtor.Invoke(new object[]
           {
               element.ExecutionContext.Frame,
               predicate,
               false,
               $"{(isXPath ? "XPath" : "selector")} '{selectorOrXPath}'{(options.Hidden ? " to be hidden" : "")}",
               options.Polling,
               options.PollingInterval,
               options.Timeout,
               new object[]
               {
                   element,
                   selectorOrXPath,
                   isXPath,
                   options.Visible,
                   options.Hidden
               }
           });
           var p = type.GetProperty("Task", BindingFlags.Instance | BindingFlags.NonPublic);

          Task<JSHandle> t=  (Task<JSHandle>) p.GetValue(waitTask);
          JSHandle handle = await  t.ConfigureAwait(false);

            return handle as ElementHandle;
        }

There is only few changes.
==========================
Also please explain me what this line do
var polling = options.Visible || options.Hidden ? WaitForFunctionPollingOption.Raf : WaitForFunctionPollingOption.Mutation;
I can see that no one use variable 'polling'

it's passed in the WaitTask constructor and then it's passed to the executed js script

oh, that 😆
you are welcome to open a pull-request for that.
the polling parameter is passed in the as options.Polling...

Our bad on the Polling code.
I don't want to add here any API which is not on Puppeteer.
I think you could add that feature on https://github.com/hlaueriksson/puppeteer-sharp-contrib
cc @hlaueriksson

@kblok aha, thanks for that link!

@Gdocal let us know if you are going to create a PR with the pooling change or you'll let that to us.

@kblok I will appreciate if you can do it


Replace Polymer with pure WebComponent

juicy-color-picker does not have any Polymer dependencies. It should be a pure WebComponent without any usage of Polymer.

+1

juicy-color-picker currently has a value property which is bound by polymer to background like <juicy-color-picker value="{{background}}"></juicy-color-picker>.
This does not work if juicy-color-picker is replaced with a pure WebComponent, not a Polymer element. https://www.polymer-project.org/0.5/articles/communication.html
So, I either have to leave juicy-color-picker as a Polymer element or adjust juicy-tile-editor-form to the new behaviour.

As far as I know this should work as long as juicy-color-picker implements attributeChanged callback. @tomalec any help?

AFAIK attributeChanged will get [object Object], unless you handle it by your own .bind.
I'm currently working on such binding for Polyjuice/launcher-include and https://github.com/Polyjuice/polyjuice-include, so once I finish you can use it in here. This should work more lightweight than making entire element Polymer one, however we would need to think about it more when migrating to 1.0 (in case of Polymer element, we will need to rewrite it as well)

AFAIK attributeChanged will get [object Object] if value is an object, unless you handle it by your own .bind.

Isn't it the case only for objects and arrays? Background color is just a string

If value is primitive it should work fine.

Yep, strings works like charm in attributeChangedCallback.

@warpech, @tomalec, looks like I am missing the point.
I have the attributeChangedCallback method:
JuicyColorPickerPrototype.attributeChangedCallback = function (attributeName) {
	switch (attributeName) {
		case "pallete":
			...
			break;
		case "value":
			...
			break;

	}
};

This lets me accept values from Polymer, but not send them back to polymer. When a color selected inside juicy-color-picker it's value updated, but Polymer does not track that change and does not update the model.
My set method looks like this:
JuicyColorPickerPrototype.setValue = function (value) {
	this.value = value;
	this.setAttribute("value", this.value);
	//this.dispatchEvent(new Event("change")); //Tried to force Polymer update value.
	this.dispatchEvent(new Event("juicy-color-picker-value-changed"));
};

The Polymer clearly says, that it only works between Polymer elements:

You're right,some time ago it worked. But right nowe we need to either make it a Polymer element, or use Polymer's Node.bind The question is which one will be easier to migrate to 1.0?
Maybe Node.bind would not be needed in 1.0, as there you could write:
<juicy-color-picker value="{{bgColor::change}}">

Could you elaborate on using Node.bind to make <juicy-tile-editor> observe changes in native <juicy-color-picker>? Would this be a one-liner?
Yes, it seems that Polymer 1.0 ↔ native element attribute data binding won't be a problem.

I have not did that, but I doubt it will be one-liner.
You can overwrite bind method on a custom element (overwrite default one given by Polymer for any HTMLElement), to change the way it works.
In here https://github.com/Polyjuice/polyjuice-include/commit/61be51cbd7eebb86c8f886561410994e4b41111c#diff-66620a0889291439d0905c22da13b9cbR76 I use it to make it possible to bind object, plus to achieve attribute-to-property binding, but I believe it should be possible to apply reflection there as well.

We agreed to freeze work on this until juicy-tile-editor is updated to Polymer 1.0


Changing Server's Netmask

Folks,
I've posted 2 messages recently (319 & 307) both referring to connecting clients appearing to have full access to Server's filesystem.
May have narrowed it down, my private network is <IP_ADDRESS> which I know is a class A network. When the PiVPN script ran it set my fixed IP fine and gateway etc but ifconfig shows netmask as <IP_ADDRESS>
I assume I need to change this to <IP_ADDRESS> but if I use
sudo ifconfig eth0 netmask <IP_ADDRESS>
the server hangs at the command.
Probably some VPN security so question is; how do I change netmask?
Other than this my PiVPN is working great.
Geffers

Managed to change my netmask to <IP_ADDRESS> but client still has full access to server's network.
Obviously has to know any passwords.

You don't want the clients to have access to the network? Just do what I have told you in #319
hash the push route YOUR NETWORK` and clients will stop to have access to other devices withing the network.
of course, they will still have access to <IP_ADDRESS> ( the Pi internal IP address ) because they HAVE TO!! So as long as you are not using your pi for anything less appropriate, and as long as you keep your client certificates secure, and you have good passwords, and you set an IPtables to drop every SSH connection from the <IP_ADDRESS> network. you will be perfectly fine!!
don't see where you want to get with this issues.
So please be more explicit or in the meanwhile, I will just ask to redtasft00 to close this issue also.

@Geffers closing this issue.
If you need further help regarding this, just shout! =)


To do

This branch just has a ToDo list. The master branch should have the file, I don't need a different ToDo branch.

So  I'm still learning to use branches properly. This merge actually ended up including files and commits I thought were contained within a different branch (the Song and Artist class code). I didn't actually want the class code included in the repository yet. I think the class files got included as part of this pull request because I unknowingly branched the ToDo branch off of song-and-artist-classes rather than master. I think it usually makes more sense to branch new ideas off of master, keeping new little project ideas separate from each other (unless they're meant to be related).


Incorrect return type in the documentation for ilisi/clisi

Report
Extremely minor but I'm currently extracting a few bits from "under the hood". Noticed that the return type of the ilisi_knn and clisi_knn calculations are incorrect. According to https://scib-metrics.readthedocs.io/en/stable/generated/scib_metrics.ilisi_knn.html it's ilisi Array of shape (n_cells,) with the iLISI score for each cell. but due to https://github.com/YosefLab/scib-metrics/blob/9d109007d8b78ad2678342db6630cc355cfd1d0b/src/scib_metrics/_lisi.py#L66 it's a single float. Analog for clisi
Version information
No response

Thanks! Happy to accept a PR with the change


On-prem data gateway

Regarding

If required, select the name of your on-premises data gateway.

This step does not make sense in the context of this page. Azure Synapse Analytics does not expose data via on-premises data gateways.

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

ID: 7f15da4f-8f22-3f68-165c-1bb0c4edc887
Version Independent ID: 29d89981-6694-8b87-d5b6-614b8680cd90
Content: Power Query Azure Synapse Analytics (SQL DW) connector - Power Query
Content Source: powerquery-docs/Connectors/AzureSQLDataWarehouse.md
Service: powerquery
GitHub Login: @bezhan-msft
Microsoft Alias: bezhan

Hi @VitalyMCT
The article has been fixed.
#please-close


Make RGBImageField support image file

When I try to make my own dataset, I find the DatasetWriter and RGBImageField does not support directly converting the image file. It would be great if we can just pass the image path to the Field and read the jpeg, png file's metadata and byte. This method would be faster than read image to tensor and encode tensor to byte.

Hi @zero0kiriyu ! In general, this should be really simple to do---FFCV can convert any indexable object into an FFCV dataset! See this guide for an example: https://docs.ffcv.io/writing_datasets.html.
Something like ffcv.fields.BytesField could be what you are looking for if you really want to avoid ever reading the images into tensor format, but I think this would be strictly slower (at loading time) than using the standard method.

@andrewilyas Probably my question is related to this:
I want to use FFCV on my tensor dataset, not ImageFolder, because I need to train SimCLR and my dataset has pairs of augmentations in the tensor type.
How is that possible?


Investigate scale of unused AWS resources across all MoJ AWS accounts

We are considering how we manage unused AWS resources. Unused resources causes two main issues:

wastes money
potential security vulnerabilities

As a central Ops team we may be in a position to help the organisation with identifying unused resources with the aim of decommissioning them to save money and reduce security risks.
As a first step we want to identify the scale of the problem to determine whether there is value in doing this work.
This story is to do the work to identify what is out there that is being unused.
Definition of done

[ ] List of unused resources per account

Requires problem definition (why are we doing this?)
Create first steps to identify scale of the issue.

Rewrite of description and scope to make ticket meaningful and actionable.

AWS CloudWatch for metrics: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html

AWS Config to find resources: https://docs.aws.amazon.com/config/latest/developerguide/how-does-config-work.html

If you wish to do it purely with AWS provided tools, try this:
figure out a tagging scheme that works for you
tag all the resources you provision, make sure nothing is left untagged
for stuff you provision outside of the terraform and are not always tagged correctly by your tagging scheme, use AWS Config service to enforce the tagging scheme
After you have all of your resources tagged, use AWS Budgets to monitor and tracked down changes in you spend and get alerts when it crosses the budget threshold you define.
Also, create and periodically review some reports within the AWS Costs Explorer to find daily changes in region spend / service spend / etc.
Using a strict and meaningful tagging scheme helps maintain a healthy account with less money going to waste.

AWS Cost and Usage report: https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/

AWS Cost explorer: https://aws.amazon.com/aws-cost-management/aws-cost-explorer/?track=costma

Dependant of HMCTS migration to Azure

New stories to be raised by HMCTS have migrated away from MoJDSD.


Bugfix/#18300  likvido app   pentest  azure blob shared key disclosure and a ssrf

#18300
This PR adds a check for the domain part in the URL passed to GetBlobSasUriAsync. We expect it to be an Azure Blob Storage link. If it's not, we'll throw an exception.

When this nuget package is published with a new version, I'll update the nuget reference on the Likvido main app.


Fixed the placement of pixels on Firefox Mobile.

I also included a temporary fix for the cooldown timer that wasn't hiding in Google Chrome Mobile because the notification code was throwing an error.
We should find a fix for the notifications on Google Chrome Mobile.
Fixes #16

Test comment.

Closing this since #30 has fixed these issues.


Use safer replace API to support older browsers

Backport of this PR: https://github.com/BrightspaceUI/core/pull/2458
It has been decided to pull this back into 20.22.5/20.22.4 because it's a safe change that might help clear up error logs and make diagnosing other issues much easier.

It... Looks like the visual diff tests are running against the new version of puppeteer on this older branch, so there are like a billion updated goldens to merge. Is it fine if I do?

I sampled a subset of the diff reports and they're all the minor visual changes I would expect from bumping Chrome. I just merged in the new goldens.

 I've been re-running these visual diff tests because they look wrong, but it's because one of the new dialog goldens I merged in earlier had a flaky failure.

Yeah it's OK to merge these changes in.

I mean at this rate I'm not sure I'm ever going to get the tests green at all, so we'll see how that goes.


More Random Randomizing in avatar/_effects.py

Description
I made the effects in avatar modification by using threading
Did you:

[x] Join the Python Discord Community?
[x] Read all the comments in this template?
[x] Ensure there is an issue open, or link relevant discord discussions?
[x] Read and agree to the contributing guidelines?

Greetings.
There seems to be no issue that was approved by a core developer before this PR was created. Please follow the contributing guidelines before making your next PR.
On another note, please see this page on making commits with great messages, to increase user knowledge of the Git history.
Thanks!