UEFI?

Hi!  Thanks for this great blog series. It's really awesome and helping me a lot in learning how an OS works.
Do you have any plans of adding support for UEFI boot? I assume the assembly would be much simpler since UEFI setup alot of that for you, including preparing a graphical framebuffer to draw on.
As for the UEFI boot loader, I assume grub-efi can be used to load a kernel from a fat/ext/ufs partition. Or, perhaps the kernel can be put on the ESP and loaded directly by the UEFI BIOS.
If I find the time, maybe I'll play around with it and do a PR. Just wanted to make sure we're not doing double work..

Booting on EFI via grub doesn't really give you anything special. But as it happens, I'm working on a pure UEFI kernel, beginnings of which I'll upload to GitHub soon. (If you wanna try on your own, I found it best to duplicate gnu-efi build process. Their README was very helpful.)

Sooo, I uploaded what I have now. https://github.com/le-jzr/sisyphos-kernel-uefi-x86_64
It's not much, but it builds, runs and prints stuff. Everything else is work in progress.

 Thanks for sharing :)

Cool! I'm planning a second edition of the tutorial with an own bootloader, since grub causes problems on many architectures. Ideally, we would support both UEFI and legacy BIOS and provide tutorials for both systems. So thanks a lot for sharing your prototype @le-jzr!
I try to create a clean branch for the second edition in the next days. I think I will focus on the legacy bootloader first, but I'll be happy to merge any UEFI related PR.

In times I wrote my own bootloader, but is in C and I want to convert it to Rust, but for now, I'm without time for that. :(

I have been working on a UEFI application written in Rust, although it could equally be used to load a kernel. There hasn't been any need for any x86 Assembly except for halting the processor.
If you like, I can upload my code and share a link when the code is more presentable (I'm learning Rust and come from a VB6/VB.NET/JavaScript background).

@toothbrush7777777 That would be awesome!

@phil-opp Sorry for the delay in answering. I'm quite busy at the moment but should be able to tidy and upload the code within a couple of weeks.

@phil-opp @johalun
I have posted my working example UEFI application at https://github.com/toothbrush7777777/uefi-app-x64.
Sorry for the long delay. 😭

@toothbrush7777777 That's awesome! I just tried it shortly and it compiled without problems. The code looks really short, that's great! I didn't manage to run it yet, but I will try again tomorrow.

@phil-opp I’m glad you like it. The most complicated part is the code for converting to UTF-16 and printing in chunks. I haven’t finished the project yet, but it at least prints and exits correctly.

@phil-opp The code doesn’t require LLVM anymore! I merged a pull request from @kkk669 to use the lld-link distributed with recent toolchain installs of Rust nightly.

Hey @toothbrush7777777, sorry that I haven't replied for so long! I was busy with the BIOS bootloader and the bootimage tool.
I'm now thinking about the best way to intregrate UEFI booting into the blog and/or bootimage. I think we have the following options:

Build a plain UEFI app, maybe with an library that provides abstractions for common functions (loading a file, retrieving the memory map, etc.). The users have to set up and mount the disk image on their own.
Add UEFI support to bootimage, so that the disk image is automatically created from the kernel executable. This would be more easy for the user, but it might be lots of work (creating the file system etc.).
Add UEFI support to bootimage (see previous point) and create an "UEFI bootloader" with the same behavior and interface as the BIOS bootloader. This means that the user continues to have an ELF executable with GNU calling convention, a nice memory map abstraction, and already a correct page table mapping for their kernel (UEFI only does identity mapping AFAIK).

Option 3 might fit best into the blog and allows the user to start with interesting things (e.g. input and output), but it would mean a lot work for us and probably too much magic for some people (albeit this is solvable by writing additional blog posts about the lower abstraction layers).
What do you think?

@phil-opp Option 3 sounds good. Setting up the disk and file-system is a lot of work, though. Someone would need to write libraries to create/edit MBR and GPT partitions, and FAT32 file-systems.
This would be similar to how the bootimage tool already works.
I won't be able to help much for a few months, though. I'm very busy with work right now.

Hello! I have been working on a UEFI abstraction crate for Rust. It follows the UEFI spec closely and could be used to implement any of the three options listed. It also contains an example Makefile that shows how to build and run a UEFI-based application under QEMU.
My next goal for this crate is to add support for file I/O. Loading a file from disk in a UEFI environment is probably not so difficult. Section 13 of the UEFI spec  describes the file system protocols that must be implemented by compliant UEFI firmware. These make it possible to do file I/O directly, without needing to implement any block device or file system drivers.
A UEFI-based version of bootimage's bootloader would just need to load the user's ELF file into memory from the EFI system partition, call UEFI's ExitBootServices routine, and then jump to the user's entry point.

I think I have a working implementation here, but there is some bad news. Evidently, VGA is not supported when booting under UEFI. This thread has some further context.
In practical terms, this means that although the kernel can be loaded and executed under a UEFI system, it won't be able to access VGA hardware to output text. At best, the VGA driver will just be writing bytes to an unimportant memory region.
If you still wish to support UEFI, I see two options:

Instead of using VGA to output text from the OS, use serial port I/O. This should work regardless of whether the system is booted under BIOS or UEFI (although I have not yet tested it), so you won't need to diverge any blog posts. The downside, of course, is that you'd need to completely replace the "VGA Text Mode" post with an analogous post about serial I/O, as well as modify the "minimal kernel" post to output "Hello world!" to serial.
Write an "efifb" driver for outputting text from the kernel. This could either be as an alternative to the "VGA Text Mode" blog post, or as a "magic" support crate that users just import and use. In either case, such a driver would be much more complex than a VGA text-mode driver, because it would need to render fonts directly into a linear frame buffer. To accomplish this, we might want to reference another implementation, such as OpenBSD's efifb driver.

All things considered, I think option 1 involves less work, and I'd be happy to assist with the changes.

@reynoldsbd Thanks a lot for your work! Sorry for replying so late.

Evidently, VGA is not supported when booting under UEFI.

That's a pity. Serial I/O is a good alternative, but only for emulation. Most real systems don't have a serial port anymore, so writing to a serial ports wouldn't have any observable effect. I haven't had the time to read up on UEFI, but isn't there some way to output some text on the EFI console?
I'm unsure how we should integrate UEFI into the blog, but I definitively plan to do it. It seems like the "support both BIOS and UEFI transparently from bootimage" approach doesn't quite work out. Making the blog UEFI-first would be cool, but too radical in my opinion for various reasons (there are still people with old BIOS systems, I don't have much experience with UEFI yet, emulation of UEFI is more difficult, cross-platform tooling does not exist yet, etc).
So I think the best way forward is to provide optional, non-transparent UEFI support: The bootimage tool gets support for building UEFI disk images from Windows executables and we add a post that explains how to transform the BIOS kernel into a hybrid BIOS/UEFI kernel. In this post the user learns how to use conditional compilation based on the target triple to select either the VGA text buffer or the EFI console for screen output. What do you think? I'm open to alternative ideas of course.

UEFI does support console I/O while "boot services" are active. The catch is that the bootloader/OS must disable those boot services (by calling ExitBootServices) before it is allowed to take full control of the system (i.e. manage page tables, setup interrupts, or directly access any hardware). After that, there doesn't seem to be any alternative for getting text to the screen except by manually rendering it.
I agree, it sounds like there's no great way to transparently support both boot methods. I think we would need the following:

a post about adding support for UEFI boot via conditional compilation (probably via a feature flag, as the target triple would likely remain unchanged), with the caveat that screen output will not work
bootimage support for building a UEFI-bootable image
an LFB-based console output driver (no small feat...) and a corresponding post? (possibly an advanced topic)

I still think there may be value in adding a serial-based console output driver, if for no other reason than to make UEFI more accessible to a beginner (as the LFB-based driver is likely to be quite complex).

I've found serial invaluable for debugging even with a working VGA driver (mainly because you aren't restricted to 25 lines), so that could be a valuable post (it also isn't too tricky, if a little bit archaic).
On the LFB-based driver, we could always write a "black-box" crate, sort of like how x86_64 is used without being implemented in the blog, but is well documented. As a beginner to OSdev / Rust, writing one from scratch might seem a bit disconcerting.

@reynoldsbd Then why don’t you set up the VGA buffer before (or after, with VBE) calling ExitBootServices? I seem to remember it being possible with one of the UEFI protocols.

@toothbrush7777777 there is a "Graphics Output Protocol" (GOP) that provides access to linear frame buffers, but these buffers correspond to pixels, not characters. AFAICT there is just no such thing as VGA or VBE when booting under UEFI, or at least none that is guaranteed to be available by the specification :/

Although not as simple as letting UEFI draw the glyphs, writing text to a linear framebuffer is still fairly simple, as long as you stick to a bitmap font. GNU Unifont is a good start, if one can swallow the GPL licensing.

Here's how it looks like now, with QEMU + OVMF for UEFI support:

Feel free to borrow code or entire crate uefi.
@GabrielMajeri IMHO, some people want to use UEFI as a standardized loader and perform "exit boot services" once booting is done. Osdev is about writing the own OS. Using UEFI API is not much different from using existing OS like Linux.

@vlad9486

Using UEFI API is not much different from using existing OS like Linux.

I specifically said I don't recommend people use UEFI APIs besides the basics.
In a computer with UEFI support and no BIOS, without using UEFI GOP or UEFI's stdout, you have no means of outputing text. You can't use VGA: you would have to write a full graphics driver for every GPU you want to support. That means thousands of lines of code to set up a framebuffer for each GPU manufacturer.
As for serial output, you can use that with QEMU, but good luck using it on a modern computer.

IMHO, some people want to use UEFI as a standardized loader and perform "exit boot services" once booting is done.

you can call ExitBootServices and keep using some of the existing protocols for standard output.
Even Linux uses UEFI's GOP if you lack a driver for your GPU.

@GabrielMajeri I didn’t know you could continue using GOP services after ExitBootServices. Do you know which other protocols can be used after ExitBootServices?

@GabrielMajeri

I specifically said I don't recommend people use UEFI APIs besides the basics.
Ok, sorry for misunderstanding, I just reply on "Issue" section.
you have no means of outputing text
Yeah, it is a problem... It is the shame that the gpu vendors could not produce standard for framebuffer access.

@GabrielMajeri Sorry for the delay, I was on vacation for the past weeks.
I haven't had the time to try it yet, but it sounds really great! The diff is much smaller than I imagined. I would be more than happy to collaborate with you to bring first-class uefi support to the blog! Thanks so much for your work!
One thing that's important to me: The guide should continue to work natively on Windows, macOS, and Linux. Is this possible with UEFI (including booting in QEMU)?
Also, I'm not 100% percent sure if we should really omit the bootloader. I like the idea of not depending on it, but the flat identity mapping done by UEFI has disadvantages to the bootloader mapping (e.g. no guard page below the stack, no support for higher half kernel). Also, we still need the bootloader for BIOS booting (which we still want to support) and I don't want to drop support for BIOS-booting.
In case we decide to keep the bootloader, we would need to add UEFI support to it. This includes adding an UEFI entry point, reading out the memory map, loading the kernel ELF file, and doing the kernel remapping. Most of these steps are already implemented, so it should be relatively little work.
In case we decide to not depend on the bootloader for UEFI, we would need to convert the bootloader to some kind of UEFI compatibility layer, so that a BIOS boot looks like an UEFI boot to the OS. This would include loading .exe binaries and providing the UEFI functions (how do they work by the way? through interrupts?). I'm not sure if this is possible, but it would be more work.
What do you think?

@GabrielMajeri Could you give me a quick overview of the steps that are needed to build your UEFI port and run it in QEMU?

@phil-opp

One thing that's important to me: The guide should continue to work natively on Windows, macOS, and Linux. Is this possible with UEFI (including booting in QEMU)?

Building the code should work, as long as Rust + rust-lld is installed.
QEMU + OVMF should work on all platforms, but the emulation can be somewhat slower if the system lacks support for hardware virtualization. That would probably involve something like KVM or HAXM for MacOS/Windows.
The Python script we use in the uefi-rs repo does require Unix named pipes for headless QEMU monitoring (when running unit tests), but I see no issue with running QEMU on Windows, with a GUI turned on.

Also, I'm not 100% percent sure if we should really omit the bootloader. I like the idea of not depending on it, but the flat identity mapping done by UEFI has disadvantages to the bootloader mapping.

I agree. My idea was to make it really easy for beginners to get something set up, and then introduce the bootloader in the secondary tutorials.
The README for uefi-rs does tell people to use a boot loader, or wrap the kernel.elf inside a kernel.efi self-extracting binary, if they need advanced features. Something like Linux kernel's EFISTUB.

I tried cargo xbuild --target x86_64-blog_os.json

Strange, it works for me. Do you have the latest cargo-xbuild and nightly Rust? Also maybe try a cargo clean?

One thing that's important to me: The guide should continue to work natively on Windows, macOS, and Linux. Is this possible with UEFI (including booting in QEMU)?

One of the problems I envisage is a cross-platform way to create the GPT image with the FAT partition. I'm using parted on Linux, but I'm not sure what you'd use on other platforms.
I wonder if a Rust-based GPT library would be a good addition to rust-osdev to build these images from
within bootimage. I had looked at this but it doesn't quite look complete enough to actually write an image with.

@IsaacWoods A comprehensive library to read and write/modify GPT headers (preferably no-std and using byte arrays or at least generic in terms of I/O) would be excellent. So would a good FAT library — perhaps fatfs would work.

@phil-opp For what it’s worth, the Windows Subsystem for Linux has grown quite mature. In most cases, Windows users can now follow the Linux instructions completely verbatim.
Would it be realistic to revise your platform compatibility requirements as follows: “The guide should continue to work natively on macOS and Linux (including WSL).”
This has two distinct benefits:

You no longer need to maintain compatibility with Windows directly, provided the Linux instructions still work under WSL
we can use a pre-built OVMF package for booting UEFI code under QEMU
we can use Linux tools like mkfs and xorriso to build a bootable UEFI image

One of the problems I envisage is a cross-platform way to create the GPT image with the FAT partition.

A good stop-gap here is that QEMU allows you to pass in a directory for it to expose as an emulated EFI system partition. This can get you a long way without ever using actual disk images.

Windows Subsystem for Linux

WSL is not Windows, and it's really quite annoying to ask people to use it for something that has no reason to be Linux-specific. It's not something your average Windows install is ever going to have set up, either, so it's only slightly less of a pain than just using a VM.

a cross-platform way to create the GPT image

You don't need to make a GPT partition (unless you plan to boot from USB on a real computer)! As it was mentioned above, using directories as emulated FAT partitions works perfectly fine. That's how I was developing for UEFI before I moved to Linux, and that's still how it works on Linux and on all platforms.

we can use a pre-built OVMF package for booting UEFI code under QEMU

kraxel provides pre-built OVMF binaries users can download, and we also mirror them on a branch of the repo.

@GabrielMajeri

I agree. My idea was to make it really easy for beginners to get something set up, and then introduce the bootloader in the secondary tutorials.

Sounds like a good solution.

Strange, it works for me. Do you have the latest cargo-xbuild and nightly Rust? Also maybe try a cargo clean? What is your OS?

It worked after a rustup update, so I guess my nightly was just too old. I got it booting in QEMU and it was relatively painless. The boot process was much slower, probably due to OVMF. I got a segment not present fault, which resulted in a double fault (I assume the same that you had in your screenshot). I didn't try to investigate it though.

I wonder if a Rust-based GPT library would be a good addition to rust-osdev to build these images from within bootimage

It would be a great addition, but I assume would be a lot of work?

Hi *,
i'll try to sum-up a couple of things to make sure i've understood some rationals correct:

Multi-Platform including Windows is and will be important.
The Bias of this Blog is not only on the OS itself, but on booting, Boot-managers,
Boot-loading etc. as well.

Or to put it the other way round: If you are only interested in teaching the OS part and could live with Unix/Linux/MacOS as development platform - What would you loose in creating an ELF/multiboot2 compliant OS and (UEFI)Boot it using grub2?
cheers, Matthias

@ms140569 Grub is not so easy to set up on Windows. Further, it only brings us to protected mode when doing a BIOS boot, so we need to do the switch to long mode ourselves.
The idea of the bootloader crate and the bootimage tool is that they set up an initial environment for your kernel, so that we can directly start with the interesting parts and not need to do any processor configuration before. Also, they don't require any C or system dependencies, so that they work natively on all three operating systems.
Currently the bootloader only supports BIOS booting, but the plan is to add support for UEFI and multiboot2 as well, either through cargo features or by creating an hybrid image (if possible).

Then why not try sth. like "efi stub" technique ? UEFI firmware will setup long mode with a flat memory map if the platform is x64. We even do not need a bootloader.

The kernel just need to ST.BS.GetMemoryMap, ST.BS.ExitBootServices, and then ST.RT.SetVirtualAddressMap whenever needed, since the last function is UEFI runtime function.

@yw662 There are few issues with using UEFI directly:

The kernel only supports UEFI and not legacy BIOS booting (e.g. for older systems). To avoid this problem we could write a BIOS bootloader that simulates an UEFI environment, but this is not easy as UEFI has lots of functionality.
UEFI creates only a basic identity mapping, so we would need to do a full remapping to improve safety of our kernel (unmap unused pages, use correct read/write/execute permissions, set up a guard page for the kernel stack, …).
An UEFI app is not directly bootable. So there is an additional step to create a bootable disk image from the .efi file. The step involves creating a file system, which is done differently on Windows and Linux.

The bootloader+bootimage combination on the other hand abstracts away the booting details, sets up a safe page mapping for the kernel, directly outputs a bootable disk image, and works natively on Windows, macOS and Linux. For this reason I think it's a good idea to keep the bootloader even for UEFI.

Any updates?

@nebrelbug Not yet, unfortunately. There's just so much other stuff to do.

There is a new tool to create a bootable UEFI image from .efi files and run the image in QEMU: https://github.com/richard-w/uefi-run. This seems really useful for adding UEFI support to bootloader/bootimage.

@phil-opp that seems really nice

It seems like the 8259 PIC is not available for UEFI: https://github.com/phil-opp/blog_os/issues/480#issuecomment-480495268. So we need a different solution for this too (e.g. directly use the APIC).

What's the state of this issue please ?

@lvndry I obviously don't know what Phil is planning to do tutorial wise, but this is further along now ecosystem wise:

We still don't have a UEFI-based solution like bootloader is for BIOS - I think the end-goal will still be to write one that can be used easily from something like bootimage, but it still needs a lot of groundwork
The uefi-rs crate is now pretty featureful, and can be used to create a UEFI bootloader without too much fuss. I have an example of one in my project here.
You will need to migrate away from legacy hardware such as the i8259 PIC to more modern stuff like the APIC. Setting up the APIC isn't too difficult with the help of my acpi and aml crates. These are things that you'll probably want to do anyway as your OS matures.

I'm currently looking into adding UEFI support to the bootloader crate. I already managed to create a small example application using uefi-rs and I'm currently trying to find a common abstraction for both BIOS and UEFI booting. There are two main challenges where we will need to adjust the tutorials:

Text Output: We currently use the VGA text mode for printing text, which is not supported with UEFI. Instead, it provides a EFI_SIMPLE_TEXT_OUPUT_PROTOCOL that can be used to print text to the screen. Unfortunately, this protocol is only available until ExitBootServices is called, so we can't use it in our kernel. (@IsaacWoods Am I understanding this correctly?)
If I understand things correctly, only the framebuffer provided by the graphics output protocol (GOP) is available after exiting boot services. This means that in order to get a common interface, we need to make the bootloader default to a pixel-based framebuffer for both BIOS and UEFI booting. We then could report the framebuffer address and metadata (resolution, stride, pixel format, etc) in the boot info.

Hardware Interrupts: As @IsaacWoods mentioned, it seems like the legacy PIC is not supported with UEFI, so we need to migrate the tutorial to the APIC. This is something that I wanted to do anyway because it is required for multi-core programming, but I originally planned to do it in a separate post together with enabling the other CPU cores. If the PIC really isn't supported at all with UEFI, it might make sense to instead rewrite the Hardware Interrupts post to directly use the APIC.

Note these are just some preliminary thoughts. I might very well forget or misunderstand something.

Instead, it provides a EFI_SIMPLE_TEXT_OUPUT_PROTOCOL that can be used to print text to the screen. Unfortunately, this protocol is only available until ExitBootServices is called, so we can't use it in our kernel. (@IsaacWoods Am I understanding this correctly?)

This is correct. Unless otherwise stated, protocols are not backed by runtime-allocated memory and so can disappear at any point after you call ExitBootServices. They specifically designed EFI_GRAPHICS_OUTPUT_PROTOCOL (GOP) with our use case in mind (not having real graphics drivers) and it's designed to supply enough information that you can write to the physical framebuffer after UEFI's involvement stops - GOP is only needed to set the framebuffer up, and not to write to it, whereas EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL is involved in the actual output as well.

the legacy PIC is not supported with UEFI, so we need to migrate the tutorial to the APIC

I haven’t touched OSDev for a while, but my next plan was to flesh out the APIC crate, which I own (the crate is almost completely empty). I would be happy to give people maintainer access to the crate if it helps.

Another option for text output, which is supported by both UEFI and BIOS, is to write to a serial port. I've used this quite a bit in the past to avoid setting up a full pixel-based framebuffer text system. It takes very little code to set up, and QEMU can forward it directly to the host console.

@IsaacWoods Thanks a lot for the explanation!

@64 That would be great, thanks a lot! Let me know if I can do anything to help.

@rpjohnst Yes, the serial port is a good option too. I personally like screen output more because it really feels like you're creating a completely new system, while serial output feels a bit like running a normal userspace program. Also, most computers today don't have an actual serial port anymore, so serial output is not accessible when running on real hardware.

@rpjohnst Yes, the serial port is a good option too. I personally like screen output more because it really feels like you're creating a completely new system, while serial output feels a bit like running a normal userspace program. Also, most computers today don't have an actual serial port anymore, so serial output is not accessible when running on real hardware.

Well, not quite. Some modern PCs do still come with serial ports. A lot of ASRock's motherboards come with internal serial port connectors.
I agree that writing to a frame-buffer does seem like creating a new system much more than writing to a serial port, though I found serial ports to be quite useful for debugging even with other VMMs like VirtualBox and VMware.

Interesting, I didn't know that. Still, there are many PCs and laptops without a serial port today. I fully agree that they're more useful than a framebuffer for debugging. Maybe the best approach would be to introduce both approaches (framebuffer and serial) at the beginning.

I don't know if this helps, but there's an MSR that allows you to get the APIC memory address without reading ACPI tables. According to Volumes 3 and 4 of the Intel SDMs, this MSR is 1Bh. Section 10.4.4 notes that bit 11 is the enable APIC bit (or as they call it, the "APIC Global Enable" flag). The manual notes that "This flag is available in the Pentium 4, Intel Xeon, and P6 family processors. It is not guaranteed to be available or available at the same location in future Intel 64 or IA-32 processors." Additionally, it specifies that the default address (bits 35:12) is FEE00000H. Is this a reliable method of acquiring the APIC address?

I don't know if this helps, but there's an MSR that allows you to get the APIC memory address without reading ACPI tables. According to Volumes 3 and 4 of the Intel SDMs, this MSR is 1Bh. Section 10.4.4 notes that bit 11 is the enable APIC bit (or as they call it, the "APIC Global Enable" flag). The manual notes that "This flag is available in the Pentium 4, Intel Xeon, and P6 family processors. It is not guaranteed to be available or available at the same location in future Intel 64 or IA-32 processors." Additionally, it specifies that the default address (bits 35:12) is FEE00000H. Is this a reliable method of acquiring the APIC address?

For those processors, probably. But I guess that would still depend on the firmware.

@ethindp MSRs generally should be avoided when possible for portability purposes, unless they've been around for a long time and are pretty much universal for relevant hardware (e.g. that one MSR that can be used for enabling syscall support).
@phil-opp I would suggest emulating UEFI on bios machines, to drastically increase portability. This, however, would mean simulating UEFI in the BIOS (this can be done with some bootloaders people made iirc, and Rust can interface with them if they exist and if it's done the right way because it all becomes machine code at some point).
However, if simulating UEFI in the BIOS, make sure that the version of UEFI that the bootloader simulates is the same as the version of UEFI being used for UEFI machines. If the versions are different, this would cause unexpected behavior.
As to making edits to the tutorials, I would suggest a third edition, as the differences between BIOS and UEFI are simply too great.

@LiamTheProgrammer Emulating UEFI on BIOS machines sounds like a good solution, provided that this is not too much work. Otherwise, we could try to create some sort of common interface that abstracts over the BIOS/UEFI details.
I'm not really keen to create a third edition since this would be a lot of work for me and churn for readers. Instead, I think it's probably better to rewrite the individual posts that are affected by the change (the post about printing to screen and setting up hardware interrupts). We would probably need to make some adjustments to the other posts (e.g. updating the QEMU screenshots), but otherwise they should stay valid.

@phil-opp Creating a common interface would be extremely hard. I think BIOS emulation shouldn't be too hard, but I could be wrong. It'd still be easier than developing a common interface, though, because for it to be fully-featured it would probably have to manually implement tons of useful UEFI functions from a UEFI specification (there are many of those) for the BIOS, which would eliminate the point anyway.
And yeah, you're right about the third edition thing.

@LiamTheProgrammer I'm not sure creating a common interface at a high level would be too challenging - I'm imagining things like load_file, create_memory_map and stuff being called from a common layer, which would then be implemented by both the UEFI and BIOS layers independently (along with an entry point).
It definitely sounds far far easier than emulating BIOS on UEFI without platform support (which is a large project itself, and not useful for our purposes). I'm not sure it's even possible as a normal UEFI application, as UEFI has control over the IDT and mode, so how would you go about allowing real-mode-style accesses and the BIOS software interrupts? There are also quirks that robust BIOS bootloaders have to work around, like some BIOSs not being able to load segments over 64k boundaries and such, that would add pointless overhead when we can just rely on UEFI's much better file protocols.

I just pushed the first prototype of the uefi bootloader here: https://github.com/rust-osdev/bootloader/tree/uefi
Use cargo uefi-build for building and cargo uefi-run for starting it in QEMU (requires OVMF). Like the BIOS bootloader, you need to set the path to your kernel binary in the KERNEL environment variable and the path to the Cargo.toml of your kernel in the KERNEL_MANIFEST_PATH environment variable when building.
The implementation currently only sets up a new page tables for mapping the kernel ELF file and then passes control to the kernel. No boot information is passed yet and no additional mappings (e.g. framebuffer, physical memory) are done yet.

@phil-opp What is cargo uefi-run?

The commands are cargo build-uefi/cargo run-uefi, sorry. Both are just aliases defined in the .cargo/config.toml so that you don't have to remember all requirement cargo arguments.

@phil-opp OK, that makes sense now.

Any news?

@IsaacWoods looks like Clover bootloader does the opposite: emulating UEFI on BIOS systems

Still working on it when I have time. Today I started implementing a new boot information struct including the memory map.
I also thought about redesigning the interface between the bootloader and bootimage crates. My basic idea is to move as much work as possible to the bootloader, so that bootimage can become a library that can be used from a local custom runner executable. The advantage of this would be that you don't have to install bootimage anymore. One requirement for this would be that cargo gains a way to reset a configured default target for a subdirectory. I opened a PR for this at https://github.com/rust-lang/cargo/pull/8638, let's see what the cargo maintainers think about it.

@phil-opp That would be pretty neat. What do you need help with regarding the bootloader right now? I'm not ultra-well-versed in UEFI, but I'd love to help! Also, for parsing executables, instead of using xmas-elf, try goblin.

Copying my status update from our gitter chat:
As a short update from my side, I got the UEFI bootloader working and integrated with the BIOS bootloader. The code is available here: https://github.com/rust-osdev/bootloader/tree/uefi
I added a new builder binary that you can use to build both the BIOS and UEFI variants of the bootloader. It's aliased to cargo builder in the .cargo/config.toml. The basic usage is:
cargo builder --kernel-binary /path/to/your/kernel/binary --kernel-manifest /path/to/your/Cargo.toml --firmware uefi

For the BIOS variant, the output of this is the disk image, so you no longer need bootimage for that. For the UEFI variant, I currently only create the .efi file, but I plan to create the fat32 image at some point too. Using OVMF, you can run the .efi file directly in QEMU.
In order to fully get rid of bootimage, I created two helper crates : bootloader_locator for locating a bootloader dependency in the dependency tree and runner_utils for detecting whether an executable is a test binary and providing a run_with_timeout function that can be used for running tests.
Using these crates, it's relatively easy to write to write an own create_disk_image builder function for our kernel: https://github.com/phil-opp/blog_os/blob/db307d89bc9e52bc0ab5eb7faf28f0d6d6637b93/disk_image/src/lib.rs . Creating an own runner executable is also possible in a few lines: https://github.com/phil-opp/blog_os/blob/db307d89bc9e52bc0ab5eb7faf28f0d6d6637b93/disk_image/src/bin/runner.rs .
I hope that letting the users create the builder and runner executables themselves instead of relying on bootimage will make the build process less magic. Another advantage is that no globally-installed tool is needed anymore, so that all project dependencies are compiled directly with the project. You no longer have to keep the installed bootimage version in sync when you upgrade the bootloader crate to a new version. Also, working with fork of the bootloader is now easier too, since you directly talk to its build interface instead of requiring bootimage as a mediator.
Unfortunately, there is also a disadvantage: Since .cargo/config.toml values apply to all subdirectories, it is no longer possible to set a default target or automatically enable the -Zbuild-std parameter right now because these setting would also apply for the builder executable of the kernel, which is stored in a subfolder. To fix this, I proposed a --ignore-local-config flag for cargo in rust-lang/cargo#8643, which would allow us to keep the config values but ignore them for the builder/runner executables. (Let me know if you can think of an easier solution to this.)

I finally got keyboard interrupts working with the IOAPIC, which means that the UEFI prototype now has all the features of the existing BIOS implementation :tada:.
As mentioned above, I had to switch from the VGA text buffer to a pixel based framebuffer because the former is not supported on UEFI. To keep things consistent, I also changed the BIOS implementation in the same way. The second difference is that we're no longer using the legacy PIC for hardware interrupts, since it is not supported either. Instead, we set up the local APIC and IOAPIC to do things properly.
The result looks like this for UEFI:

For BIOS systems, it should be exactly the same:

(There are only some differences in the default values of some registers.)
This means that we don't need to do anything special for either UEFI or BIOS from the kernel side. The new boot info structure provides a common interface that works with both firmware variants.
The next step is to merge and publish the new bootloader implementation (after some polishing). Then I'll update and restructure the blog for the new implementation, including rewriting some posts ("VGA Text Buffer" and "Hardware Interrupts"). Since the IOAPIC requires allocations, I plan to move the new "Hardware Interrupt" post after the memory management posts.

@64 I created a small apic crate for accessing the most important registers of the local APIC and the IOAPIC. You mentioned above that you also wanted to create an apic crate. Do you want to build your own or would you consider collaborating on this under the rust-osdev organization, e.g. starting from my prototype? I don't have my code online yet, put I plan to push it in the next few days. If you're interested in collaborating, I could ping you after pushing it.

@64 I pushed my implementation to https://github.com/phil-opp/apic.

@phil-opp I’m happy to collaborate - putting it on the rust-osdev organisation sounds like a good idea.
I’ve given you owner access to the apic crate. Feel free to nuke what’s there and replace it with your prototype (my code is just a stub atm).

Awesome, thanks a lot! I moved my repo to https://github.com/rust-osdev/apic and added you to new apic team with access to that repo. Feel free to extend or change my implementation if you like, it is just a first prototype.

is this still being worked on?

is this still being worked on?

Yes.

I know it's not September yet for the annual check-in, but I'm enjoying the series thus far!!

Could there be a way to easily configure USB I/O if you’re using one machine to program another machine via USB? Like if I had a raspberry pi wired to my laptop?

After exitting boot services (which you have to do before you can use many features a proper PS needs), the firmware will no longer provide any help for that.  Something easier if you got another raspberry pi or something like that would be to connect the UART pins between the raspberry pi and the other device. This would allow you to read whatever is sent by the OS through the UART (which is much easier to write a driver for) on the other device and send it back to your computer. Make sure to connect the rx pin on one side with the tx on the other side and vice versa. Also you have to be very careful that both sides use the same voltage for the UART. For example I believe an Arduino uses a higher voltage than a Raspberry PI, which can damage the Raspberry PI.


[KOGITO-842] - Operator: jbpm-quarkus-example not starting after nati…

…ve build due to missing protobuf files
Signed-off-by: spolti<EMAIL_ADDRESS>Many thanks for submiting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[ ] You have read the contributors guide
[ ] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[ ] Pull Request contains link to the JIRA issue
[ ] Pull Request contains description of the issue
[ ] Pull Request does not include fixes for issues other than the main ticket
[ ] Your feature/bug fix has a unit test that verifies it
[ ] You've tested the new feature/bug fix in an actual OpenShift cluster

we had a follow-up for that https://issues.redhat.com/browse/KOGITO-959 :)
I will close it when this one is merged.
Let me check first that it works correctly

Ok, my bad, didn't see the linked followup on jira.

np

@ricardozanini no worries, I always forget to do this =D


Update version number for jar release

Codecov Report

Merging #57 (a328944) into master (b3d1f16) will not change coverage.
The diff coverage is 0.00%.

@@            Coverage Diff            @@
##             master      #57   +/-   ##
=========================================
  Coverage     70.51%   70.51%
  Complexity      545      545
=========================================
  Files            92       92
  Lines          1740     1740
  Branches        202      202
=========================================
  Hits           1227     1227
  Misses          449      449
  Partials         64       64

Impacted Files
Coverage Δ

src/main/java/seedu/address/MainApp.java
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


How to deserialize Pkcs12 from openssl::Pkcs12's serialization?

I have TLS working on my server where I've built a Pkcs12 (.pfx) file from the key/cert generated by Let's Encrypt. That works fine.
But now I also want my server to be able to generate its own signed cert in memory on server boot. I use rust-openssl to generate a key/cert pair and then DER-serialize it in memory, but I'm having trouble deserializing it to native_tls::Pkcs12 so that I can initialize my serve with it.

I'm on OSX.
I took the key/cert generation in generate_pair() from the docs' example. Ideally I would change it so that it uses the same parameters as CLI openssl's keygen, but I'm still researching that.
Why doesn't openssl::Pkcs12::from_der() take a password as an argument? It decodes the archive without one.

Anyways, this snippet demonstrates that native_tls is unable to deserialize the pfx file that rust-openssl generated.
Alternatively, is there a better solution for get the server to generate and use its own self-signed cert?
extern crate native_tls;
extern crate openssl;

use openssl::x509::{self, X509, X509Name, X509Ref};
use openssl::pkey::{PKey, PKeyRef};
use openssl::hash::MessageDigest;
use openssl::rsa::Rsa;

use openssl::pkcs12::Pkcs12Builder;
use openssl::pkcs12::Pkcs12;

// Generates a key/cert pair
fn generate_pair() -> (PKey, x509::X509) {
    let rsa = Rsa::generate(2048).unwrap();
    let key = PKey::from_rsa(rsa).unwrap();

    let mut name = X509Name::builder().unwrap();
    name.append_entry_by_nid(openssl::nid::COMMONNAME, "example.com").unwrap();
    let name = name.build();

    let mut builder = X509::builder().unwrap();
    builder.set_version(2).unwrap();
    builder.set_subject_name(&name).unwrap();
    builder.set_issuer_name(&name).unwrap();
    builder.set_pubkey(&key).unwrap();
    builder.sign(&key, MessageDigest::sha256()).unwrap();

    let cert: openssl::x509::X509 = builder.build();

    (key, cert)
}

fn main() {
    let (key, cert) = generate_pair();

    // Let's turn out key/cert pair into a pkcs12 archive with a password of "secret"
    const PASSWORD: &str = "secret";

    let pkcs12 = openssl::pkcs12::Pkcs12::builder()
        .build(password, "friendly_name", &*key, &cert)
        .unwrap();

    // The DER-encoded bytes of the archive
    let der = pkcs12.to_der().unwrap();

    // openssl's Pkcs12 struct can deserialize the round-trip.
    let pkcs12 = openssl::pkcs12::Pkcs12::from_der(&der).unwrap();

    // But native_tls' Pkcs12 cannot.
    let native_tls_pfx = native_tls::Pkcs12::from_der(&der, PASSWORD).unwrap();
    // (Fails)
}

On OSX, the error is:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { code: -25257, message: "Unknown format in import." }'

On Linux, the error is:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Ssl(ErrorStack([Error { code: 218570907, library: "asn1 encoding routines", function: "ASN1_get_object", reason: "too long", file: "asn1_lib.c", line: 147 }, Error { code: 218529894, library: "asn1 encoding routines", function: "ASN1_CHECK_TLEN", reason: "bad object header", file: "tasn_dec.c", line: 1185 }, Error { code: 218595386, library: "asn1 encoding routines", function: "ASN1_ITEM_EX_D2I", reason: "nested asn1 error", file: "tasn_dec.c", line: 219, data: "Type=ASN1_TIME" }, Error { code: 218640442, library: "asn1 encoding routines", function: "ASN1_TEMPLATE_NOEXP_D2I", reason: "nested asn1 error", file: "tasn_dec.c", line: 697, data: "Field=notBefore, Type=X509_VAL" }, Error { code: 218640442, library: "asn1 encoding routines", function: "ASN1_TEMPLATE_NOEXP_D2I", reason: "nested asn1 error", file: "tasn_dec.c", line: 697, data: "Field=validity, Type=X509_CINF" }, Error { code: 218640442, library: "asn1 encoding routines", function: "ASN1_TEMPLATE_NOEXP_D2I", reason: "nested asn1 error", file: "tasn_dec.c", line: 697, data: "Field=cert_info, Type=X509" }, Error { code: 218919022, library: "asn1 encoding routines", function: "ASN1_item_unpack", reason: "decode error", file: "asn_pack.c", line: 205 }, Error { code: 587686002, library: "PKCS12 routines", function: "PKCS12_parse", reason: "parse error", file: "p12_kiss.c", line: 132 }]))', /checkout/src/libcore/result.rs:916:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Why doesn't openssl::Pkcs12::from_der() take a password as an argument? It decodes the archive without one.

The password is provided when you extract values from the archive: https://docs.rs/openssl/0.10.5/openssl/pkcs12/struct.Pkcs12.html#method.parse
The native_tls call combines those two calls which is why one is succeeding and the other isn't.
It may be failing to parse because the X509 certificate isn't valid. It's missing notBefore and notAfter entries, etc.

@sfackler Wow... thanks! You were right. I just had to set notBefore/notAfter. I don't think I would've figured that out myself for some time.
I don't have the energy for it at the moment, but it'd definitely be nice to sometime add these lines to the x509 example https://docs.rs/openssl/0.10.5/openssl/x509/index.html#example:
use openssl::asn1::Asn1Time;

// ...
builder.set_not_before(&Asn1Time::days_from_now(0).unwrap());
builder.set_not_after(&Asn1Time::days_from_now(7).unwrap());

That example's been removed: https://github.com/sfackler/rust-openssl/commit/f645165ee2b41f9c15d9a7d8f3eec56000b7e445. X509 is complex enough that people shouldn't really be trying to construct certificates manually unless they already know what they're doing.

Agreed. I would've never had an issue had I remembered to look for an examples directory. That's a great demo.
Thanks again.


don't refresh page on form submit

This prevents the page from reloading if you use the enter key to check your answer.
https://stackoverflow.com/questions/25615758/dont-refresh-page-when-enter-key-is-pressed

@trevorgunn goes into the QuizQuestions hall of fame!


loop.create_task without saving a reference to the result

Hi! Thank you for your library :smiley:
I have a question about this line of code:
loop.create_task(new_coro())

I am confused that the link to the result is not saved here.
Because there is a warning about this in the documentation.
Thank you in advance for your response.

Yes it's odd isn't it?  I already noticed this quite a while ago. Check this out:
import gc
import asyncio

async def blah():
    for i in range(20):
        print(i)
        await asyncio.sleep(1)

async def main():
    loop = asyncio.get_running_loop()
    loop.create_task(blah())
    gc.collect()

    await asyncio.sleep(20)
    print('main done')

if __name__ == '__main__':
    asyncio.run(main())

Even immediately calling gc.collect() doesn't make the referenceless task disappear.  I don't know why, but if you find out I would love to know :)

Ah interesting.
I should probably make the change to assign the result to something anyway, because you never know if a future version of python becomes more aggressive to remove garbage earlier. It just seems silly to assign to a var that isn't used.

It just seems silly to assign to a var that isn't used.

Yeah.
Maybe, you can use a dummy variable here:
_ = loop.create_task(new_coro())

Yes ofc, but I hate needing to do that 😄

Also, it's plausible in the general case that _ might get used for something else in the same scope. Maybe not this project, but as a general solution. So _ on it's own is probably not a good idea. Perhaps just background_tasks like the docs suggested.

Yes, this looks like the best solution.
P.S. I was worried about deleting the task after it's done, but it turns out there is already a solution based on add_done_callback in the documentation :smile: .

Small example based on Asyncio Disappearing Task Bug
# demo.py
import asyncio
import gc

async def bla():
    loop = asyncio.get_running_loop()
    future = loop.create_future()
    await future

async def main():
    asyncio.create_task(bla())

    for i in range(11):
        print('[gc collect]', i)
        gc.collect()
        await asyncio.sleep(1)
    print('main done')

if __name__ == '__main__':
    asyncio.run(main())

$ python -m demo
[gc collect] 0
[gc collect] 1
Task was destroyed but it is pending!
task: <Task pending name='Task-2' coro=<bla() running at /home/user/demo.py:8> wait_for=<Future pending cb=[Task.task_wakeup()]>>
[gc collect] 2
...
[gc collect] 10
main done

fwiw, this same pattern is repeated in a couple of other places:
https://github.com/cjrh/aiorun/blob/aec5682fee41c709b34cf85c416c14f325f4b449/aiorun.py#L221
https://github.com/cjrh/aiorun/blob/aec5682fee41c709b34cf85c416c14f325f4b449/aiorun.py#L243
I have no idea if there is even a theoretical scenario where this could cause a problem, though.


doesn't work with ember-lodash v4

context here https://github.com/mike-north/ember-lodash/issues/86#issuecomment-280405970

resolved in https://github.com/kellyselden/babel-plugin-fake-import-specifiers/releases/tag/v1.1.2


Get Currently video Height quality

I need after select vide quality using trackSelector,  I need to get currently video height quality , how I can do that's?

I assume this is a follow-up to https://github.com/androidx/media/issues/880.
You can listen to Player.Listener.onVideoSizeChanged.
See more info about listening to player events: https://developer.android.com/guide/topics/media/exoplayer/listening-to-player-events


Ignore MemberAlreadyExist exception during startup.

During service startup, if service registry is enabled we register the service.
If the service member ID already exists in the registry, the service start up fails with an exception MemberAlreadyExist.
This change will ignore this exception and continue with service startup.
Why do we need this change?
Consider a scenario where pod with a Stackstorm service is running.

During startup this pod would have been registered in the service registry with hostname = pod name.
Let's say the service container inside the pod is OOMKilled.
Now, because of OOM kill the de-reregistration of service from the registry might not complete.
After some backoff, when the container is able to start up again in the same pod with the same pod name, the service startup fails with MemberAlreadyExist exception because the de-reregistration process did not complete.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Khushboo Bhatia seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Khushboo Bhatia seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@khushboobhatia01 I rebased and fixed the author email. Now the CLA bot is not complaining.


[framework] conditional removal of animated opacity

Sort of fixes https://github.com/flutter/flutter/issues/113879
Reduces raster time from ~14ms to 4ms on a Pixel 6 for the test app linked in the issue.

@dnfield @goderbauer curious to what you think of this. I don't love the conditional behavior, but the chip scenario has me concerned that we're leaving a ton of performance on the table elsewhere

I think I'd rather see something from dart:ui about whether layers involve matrix slamming or not.
That flag could return false if there's no raster cache, or if the engine has been built in a mode where the raster cache doesn't involve matrix slamming, or perhaps false if the DPR is high enough where we choose not to?

That flag could return false if there's no raster cache, or if the engine has been built in a mode where the raster cache doesn't involve matrix slamming, or perhaps false if the DPR is high enough where we choose not to?

The former cases essentially don't exist in production yet, though it might with impeller. The device pixel ratio is really sort of the issue, where it seems like we can get away with the snapping if the DPR is high enough.

This isn't the right fix


Prepend libra to metrics package

Motivation
To publish to crates.io, all packages need to have unique names. Prepending libra to the names of all packages provides unique names for all packages. This PR prepends libra to the metrics package.
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Only cosmetic changes, existing tests should suffice.
Related PRs
#1226
#1235
#1350
#1353
#1371

CC @bmwill

:umbrella: The latest upstream changes (presumably 1c6f73e0eafe6cc74f0736e45bad5115f7718718) made this pull request unmergeable. Please resolve the merge conflicts.

@bmwill can we get this through before I have to rebase again?

@bors-libra r+

:pushpin: Commit 4f9f899 has been approved by bmwill

:hourglass: Testing commit 4f9f899002cdd403fe53d1019de27ef389e8679a with merge a5615f1cf1a14671c247b09ff0f8f0d874ab490e...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: bmwill
Pushing a5615f1cf1a14671c247b09ff0f8f0d874ab490e to master...


Implementation for Datasources operations

/azp run python - search - tests

I fixed the small conflict from the SearchIndexClient rename PR


#619 - Remove version module and tests.

The build doesn't bump this anymore and it doesn't make sense when consumed via a package manager
because it's in the package manifest already. It only makes sense in a global world which is quickly
going away.
BREAKING CHANGE: remove version module #619

I've always found it useful for debugging in the console (sanity check, is this the version I think it is?) however if it's going to be a headache to maintain, it's not a great loss.

It's mostly because it will always be a custom build step (I think?) to maintain and it really only makes sense when you don't use a package manager.


Add fpx website

This is a WIP PR for the upcoming FPX landing/docs page.
It uses Astro (Starlight) for the docs page, Tailwind for styling (to align with fpx itself), and MDX for the content.

my understanding is we're going to merge this as a landing page only build, then create a new branch to expand content, so i've marked as ready for review (pending updated screenshots)


ImportError at run_train.sh

I try to execute run_train.sh. It occurred error.
$ ls
ILSVRC2012_bbox_train_v2.tar.gz  ILSVRC2012_img_train.tar  LICENSE    __init__.py     configs        datasets                          models        predict.py              requirements.txt   run_tensorboard.sh  squeezenext_architecture.py  tabby_cat.jpg          tf-records  train     validation
ILSVRC2012_img_test.tar          ILSVRC2012_img_val.tar    README.md  bounding_boxes  dataloader.py  imagenet_2012_bounding_boxes.csv  optimizer.py  preprocess_imagenet.sh  run_cpu_docker.sh  run_train.sh        squeezenext_model.py         tensorflow_extentions  tools       train.py
$ cat run_train.sh
#!/usr/bin/env bash
DATE=`date '+%Y-%m-%d_%H-%M'`
#TRAIN_PATH="/usr/local/share/models/"
TRAIN_PATH="/home/sounansu/anaconda3/squeezenext-tensorflow/models/"
TRAIN_DIR=$TRAIN_PATH$DATE

if [[ ! -e $DATA_DIR ]]; then
    echo "Data dir $DATA_DIR does not exists." 1>&2
    exit 1
fi
if [[ ! -e $TRAIN_DIR ]]; then
    mkdir $TRAIN_DIR
elif [[ ! -d $TRAIN_DIR ]]; then
    echo "Model dir $TRAIN_DIR already exists but is not a directory" 1>&2
fi

PYTHONPATH="./" python train.py \
--model_dir $TRAIN_DIR \
--configuration "v_1_0_SqNxt_23" \
--batch_size 256 \
--num_epochs 120 \
--training_file_pattern $DATA_DIR"train-*" \
--validation_file_pattern $DATA_DIR"validation-*"
$ bash run_train.sh
/home/sounansu/anaconda3/envs/squeezenext-tensorflow/lib/python3.5/site-packages/h5py/__init__.py:36: FutureWarning: Conversion of the second argument of issubdtype from `float` to `np.floating` is deprecated. In future, it will be treated as `np.float64 == np.dtype(float).type`.
  from ._conv import register_converters as _register_converters
Traceback (most recent call last):
  File "train.py", line 3, in <module>
    from configs import configs
  File "/home/sounansu/anaconda3/squeezenext-tensorflow/configs/__init__.py", line 6, in <module>
    configs[module[:-3]] = __import__(module[:-3], locals(), globals()).training_params
ImportError: No module named 'v_1_0_G_SqNxt_23'

Please gime me some advices!

I change python3 to python2.
There was no errors at Import time.
But, another errors are occured.
WARNING:tensorflow:No new checkpoint ready for evaluation. Skip the current evaluation pass as evaluation results are expected to be same for the same checkpoint.
Traceback (most recent call last):
  File "train.py", line 88, in <module>
    tf.app.run(main)
  File "/home/sounansu/anaconda3/envs/squeezenext-tensorflow/lib/python2.7/site-packages/tensorflow/python/platform/app.py", line 126, in run
    _sys.exit(main(argv))
  File "train.py", line 78, in main
    tf.estimator.train_and_evaluate(classifier, train_spec, eval_spec)
  File "/home/sounansu/anaconda3/envs/squeezenext-tensorflow/lib/python2.7/site-packages/tensorflow/python/estimator/training.py", line 439, in train_and_evaluate
    executor.run()
  File "/home/sounansu/anaconda3/envs/squeezenext-tensorflow/lib/python2.7/site-packages/tensorflow/python/estimator/training.py", line 518, in run
    self.run_local()
  File "/home/sounansu/anaconda3/envs/squeezenext-tensorflow/lib/python2.7/site-packages/tensorflow/python/estimator/training.py", line 663, in run_local
    'Eval status: {}'.format(eval_result.status))
RuntimeError: There was no new checkpoint after the training. Eval status: no new checkpoint

I want another advices!

Could you maybe post all the outputs of the console so I may have an idea at which point in the process the error occurs?

@Timen ! thank you for your reply.
I change run_train.sh for my directory.
$ cat run_train.sh
#!/usr/bin/env bash
DATE=`date '+%Y-%m-%d_%H-%M'`
#TRAIN_PATH="/usr/local/share/models/"
TRAIN_PATH="/home/sounansu/anaconda3/squeezenext-tensorflow/models/"
TRAIN_DIR=$TRAIN_PATH$DATE

if [[ ! -e $DATA_DIR ]]; then
    echo "Data dir $DATA_DIR does not exists." 1>&2
    exit 1
fi
if [[ ! -e $TRAIN_DIR ]]; then
    mkdir $TRAIN_DIR
elif [[ ! -d $TRAIN_DIR ]]; then
    echo "Model dir $TRAIN_DIR already exists but is not a directory" 1>&2
fi

PYTHONPATH="./" python train.py \
--model_dir $TRAIN_DIR \
--configuration "v_1_0_SqNxt_23" \
--batch_size 256 \
--num_epochs 120 \
--training_file_pattern $DATA_DIR"train-*" \
--validation_file_pattern $DATA_DIR"validation-*"

and the full output are below
$ export DATA_DIR=./;bash run_train.sh
INFO:tensorflow:Using default config.
INFO:tensorflow:Using config: {'_save_checkpoints_secs': 600, '_session_config': None, '_keep_checkpoint_max': 5, '_task_type': 'worker', '_train_distribute': None, '_is_chief': True, '_cluster_spec': <tensorflow.python.training.server_lib.ClusterSpec object at 0x7f989e5201d0>, '_evaluation_master': '', '_save_checkpoints_steps': None, '_keep_checkpoint_every_n_hours': 10000, '_service': None, '_num_ps_replicas': 0, '_tf_random_seed': None, '_master': '', '_num_worker_replicas': 1, '_task_id': 0, '_log_step_count_steps': 100, '_model_dir': '/home/sounansu/anaconda3/squeezenext-tensorflow/models/2018-11-01_20-36', '_global_id_in_cluster': 0, '_save_summary_steps': 100}
INFO:tensorflow:Total steps = 600480, num_epochs = 120, batch size = 256
INFO:tensorflow:Running training and evaluation locally (non-distributed).
INFO:tensorflow:Start train and evaluate loop. The evaluate will happen after 1800 secs (eval_spec.throttle_secs) or training is finished.
INFO:tensorflow:Calling model_fn.
INFO:tensorflow:Done calling model_fn.
INFO:tensorflow:Create CheckpointSaverHook.
INFO:tensorflow:Graph was finalized.
2018-11-01 20:36:44.617115: I tensorflow/core/platform/cpu_feature_guard.cc:140] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
2018-11-01 20:36:44.726167: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:898] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2018-11-01 20:36:44.726652: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1356] Found device 0 with properties:
name: GeForce GTX 1080 Ti major: 6 minor: 1 memoryClockRate(GHz): 1.6705
pciBusID: 0000:1d:00.0
totalMemory: 10.91GiB freeMemory: 7.35GiB
2018-11-01 20:36:44.726667: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1435] Adding visible gpu devices: 0
2018-11-01 20:36:45.091236: I tensorflow/core/common_runtime/gpu/gpu_device.cc:923] Device interconnect StreamExecutor with strength 1 edge matrix:
2018-11-01 20:36:45.091273: I tensorflow/core/common_runtime/gpu/gpu_device.cc:929]      0
2018-11-01 20:36:45.091279: I tensorflow/core/common_runtime/gpu/gpu_device.cc:942] 0:   N
2018-11-01 20:36:45.091465: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1053] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 7100 MB memory) -> physical GPU (device: 0, name: GeForce GTX 1080 Ti, pci bus id: 0000:1d:00.0, compute capability: 6.1)
INFO:tensorflow:Running local_init_op.
INFO:tensorflow:Done running local_init_op.
INFO:tensorflow:Saving checkpoints for 0 into /home/sounansu/anaconda3/squeezenext-tensorflow/models/2018-11-01_20-36/model.ckpt.
INFO:tensorflow:Loss for final step: None.
INFO:tensorflow:Calling model_fn.
INFO:tensorflow:Done calling model_fn.
INFO:tensorflow:Starting evaluation at 2018-11-01-11:36:59
INFO:tensorflow:Graph was finalized.
2018-11-01 20:37:01.836180: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1435] Adding visible gpu devices: 0
2018-11-01 20:37:01.836220: I tensorflow/core/common_runtime/gpu/gpu_device.cc:923] Device interconnect StreamExecutor with strength 1 edge matrix:
2018-11-01 20:37:01.836227: I tensorflow/core/common_runtime/gpu/gpu_device.cc:929]      0
2018-11-01 20:37:01.836237: I tensorflow/core/common_runtime/gpu/gpu_device.cc:942] 0:   N
2018-11-01 20:37:01.836348: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1053] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 7100 MB memory) -> physical GPU (device: 0, name: GeForce GTX 1080 Ti, pci bus id: 0000:1d:00.0, compute capability: 6.1)
INFO:tensorflow:Restoring parameters from /home/sounansu/anaconda3/squeezenext-tensorflow/models/2018-11-01_20-36/model.ckpt-0
INFO:tensorflow:Running local_init_op.
INFO:tensorflow:Done running local_init_op.
INFO:tensorflow:Finished evaluation at 2018-11-01-11:37:03
INFO:tensorflow:Saving dict for global step 0: Recall@1 = 0.0, Recall@5 = nan, global_step = 0, loss = 0.0
INFO:tensorflow:Calling model_fn.
INFO:tensorflow:Done calling model_fn.
INFO:tensorflow:Create CheckpointSaverHook.
INFO:tensorflow:Graph was finalized.
2018-11-01 20:37:11.220277: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1435] Adding visible gpu devices: 0
2018-11-01 20:37:11.220318: I tensorflow/core/common_runtime/gpu/gpu_device.cc:923] Device interconnect StreamExecutor with strength 1 edge matrix:
2018-11-01 20:37:11.220325: I tensorflow/core/common_runtime/gpu/gpu_device.cc:929]      0
2018-11-01 20:37:11.220331: I tensorflow/core/common_runtime/gpu/gpu_device.cc:942] 0:   N
2018-11-01 20:37:11.220474: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1053] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 7100 MB memory) -> physical GPU (device: 0, name: GeForce GTX 1080 Ti, pci bus id: 0000:1d:00.0, compute capability: 6.1)
INFO:tensorflow:Restoring parameters from /home/sounansu/anaconda3/squeezenext-tensorflow/models/2018-11-01_20-36/model.ckpt-0
INFO:tensorflow:Running local_init_op.
INFO:tensorflow:Done running local_init_op.
INFO:tensorflow:Saving checkpoints for 0 into /home/sounansu/anaconda3/squeezenext-tensorflow/models/2018-11-01_20-36/model.ckpt.
INFO:tensorflow:Loss for final step: None.
WARNING:tensorflow:No new checkpoint ready for evaluation. Skip the current evaluation pass as evaluation results are expected to be same for the same checkpoint.
Traceback (most recent call last):
  File "train.py", line 88, in <module>
    tf.app.run(main)
  File "/home/sounansu/anaconda3/envs/squeezenext-tensorflow/lib/python2.7/site-packages/tensorflow/python/platform/app.py", line 126, in run
    _sys.exit(main(argv))
  File "train.py", line 78, in main
    tf.estimator.train_and_evaluate(classifier, train_spec, eval_spec)
  File "/home/sounansu/anaconda3/envs/squeezenext-tensorflow/lib/python2.7/site-packages/tensorflow/python/estimator/training.py", line 439, in train_and_evaluate
    executor.run()
  File "/home/sounansu/anaconda3/envs/squeezenext-tensorflow/lib/python2.7/site-packages/tensorflow/python/estimator/training.py", line 518, in run
    self.run_local()
  File "/home/sounansu/anaconda3/envs/squeezenext-tensorflow/lib/python2.7/site-packages/tensorflow/python/estimator/training.py", line 663, in run_local
    'Eval status: {}'.format(eval_result.status))
RuntimeError: There was no new checkpoint after the training. Eval status: no new checkpoint

What version of tensorflow are you using?
What kind of data are you using? Did you create the dataset according to the instructions here or did you create your own tf records?

@Timen  Thank you! My answers are below.

What version of tensorflow are you using?

$ python -c 'import tensorflow as tf; print(tf.__version__)'
1.8.0

I prepared datas as below.
I get ILSVRC2012_img_test.tar ILSVRC2012_img_train.tar ILSVRC2012_img_val.tar ILSVRC2012_bbox_train_v2.tar.gz and copy to squeezenext-tensorflow directory
and
export DATA_DIR=./
bash datasets/process_downloaded_imagenet.sh $DATA_DIR

below list are after execute command
$ ls
ILSVRC2012_bbox_train_v2.tar.gz   requirements.txt
ILSVRC2012_img_test.tar           run_cpu_docker.sh
ILSVRC2012_img_train.tar          run_tensorboard.sh
ILSVRC2012_img_val.tar            run_train.sh
LICENSE                           squeezenext
README.md                         squeezenext.zip
__init__.py                       squeezenext_architecture.py
bounding_boxes                    squeezenext_architecture.pyc
configs                           squeezenext_model.py
dataloader.py                     squeezenext_model.pyc
dataloader.pyc                    tabby_cat.jpg
datasets                          tensorflow_extentions
imagenet_2012_bounding_boxes.csv  tf-records
models                            tmp.log
optimizer.py                      tools
optimizer.pyc                     train
predict.py                        train.py
preprocess_imagenet.sh            validation

and
bash run_train.sh

Ok I see you set you DATA_DIR to the same directory as your code directory. I didn't do it like this, and it is also smarter to have the imagenet data in a different directory than the code (keeps it nicely seperated).
However it might still work fine, are there tf-records inside the tf-records folder? And is the size of the tf-records folder pretty big think around 100GB if i remember correctly?

If the data is in the tf-records folder I think I made a mistake and I'll update the code but you first need to make sure the tf-records were generated.

@Timen  Thanks quickly response.
$ du -s *
20376   ILSVRC2012_bbox_train_v2.tar.gz
13365056        ILSVRC2012_img_test.tar
144431156       ILSVRC2012_img_train.tar
6586844 ILSVRC2012_img_val.tar
4       LICENSE
8       README.md
0       __init__.py
2202748 bounding_boxes
24276   configs
8       dataloader.py
8       dataloader.pyc
1328    datasets
29016   imagenet_2012_bounding_boxes.csv
85300   models
4       optimizer.py
4       optimizer.pyc
4       predict.py
4       preprocess_imagenet.sh
4       requirements.txt
4       run_cpu_docker.sh
4       run_tensorboard.sh
4       run_train.sh
52612   squeezenext
5808    squeezenext.zip
8       squeezenext_architecture.py
8       squeezenext_architecture.pyc
8       squeezenext_model.py
8       squeezenext_model.pyc
988     tabby_cat.jpg
32      tensorflow_extentions
150653544       tf-records
0       tmp.log
44      tools
290518576       train
4       train.py
6655764 validation
$ ls tf-records |wc
   1152    1152   24832

Are there correct?
If it is correct, another member of our team will try another machine.
(So, if HDD  has enough space.......)
Thank you!

Great! I'll quickly explain what I did wrong, first of all I didn't fully test the setup process on a clean system so thank you for testing it for me. Second tensorflow estimators are notorious for outputting very little debug data but in my experience when everything runs without errors but nothing happens something is wrong with the input data.
In this case it was looking for the train and validation tf-records in the DATA_DIR, however I changed the process_download_imagenet script to output those to $DATA_DIR/tf-records/. So that is all I did i updated the run_train script to look for the tf-records in the  $DATA_DIR/tf-records/ folder instead of $DATA_DIR.


[BUG] HiveCote output

Describe the bug
Fitting hive-cote model gives unrecognizable number outputs and doesn't finish executing, even on a small dataset.

Further details:
I checked the code of the class too, but I don't understand where the outputs come from, since its simply fitting 4 different algos (Shapelettransform, TimeSeriesForest, RISE, cBOSS) and saving the weights. I can't see when the code terminates.
Versions
sklearn: 0.23.1
from sktime import show_versions; show_versions()

System:
    python: 3.8.5
executable: C:\Users\
   machine: Windows-10

Python dependencies:
          pip: 21.0.1
   setuptools: 50.3.0.post20201006
      sklearn: 0.23.1
       sktime: 0.5.3
  statsmodels: 0.12.2
        numpy: 1.19.5
        scipy: 1.4.1
       Cython: 0.29.21
       pandas: 1.0.5
   matplotlib: 3.2.2
       joblib: 0.17.0
        numba: 0.52.0
     pmdarima: None
      tsfresh: None

Thanks for the great repo!

@TonyBagnall @MatthewMiddlehurst can you look into this please when you have time?
I don't think it's a good idea to move things out of contrib if they do not pass the basic tests ("HIVECOTEV1" is currently excluded here). Was there any issue with the test why HIVECOTE couldn't pass?

I think we need to move this back to contrib to debug it! I would recommend using Rocket for now, its very fast and not significantly less accurate than HiveCote 1.0 on the UCR data

Thanks @TonyBagnall for the quick reply!
@MJimitater if you're interested in looking into this to find out what has gone wrong, that'd be much appreciated too!

Agreed with @TonyBagnall , I think i moved this out of contrib but should not have done. I am not familiar with the ShapeletTransformClassifier, but if I was to guess the problem with be here. It is contracted for an hour (so are each of the cross-validation classifiers) so it should be taking the majority of the time. No idea what those value outputs are but will take a look.
When it comes to testing HIVE-COTE the issue is time really. It could be parameterised to avoid the STC contract which would be a massive time sink, but even then would most likely be very slow. Each of the constituent classifiers are already being tested, which is most of the classifier.

@MatthewMiddlehurst yes I was worrying about run time too, including it without tests isn't great either, not sure what the best solution is.

Yeah that really should not have been outside contrib! I have made a number of fixes and additions to the HC1 class. I'm happy to keep it where it is with these changes.
I have included a verbose setting to give periodic progress updates as suggested, as well as a n_jobs parameter to make use of multiple threads where applicable (mainly the cross-validation).
Testing remains an issue, I have set it up so you can alter the parameters of each individual classifier which should help, but I think its going to be a costly one even with that. Any suggestions welcome here or on the PR.

Dear @mloning , @TonyBagnall and @MatthewMiddlehurst , thank you for your quick support on this issue!
I tested the fix, the execution on my small dataset (500x10) now doesn't run limitlessly +30h anymore and there are some verbose outputs! So thanks again!!


Support for plantuml

This is a fantastic tool! Any plans for plantuml support?

Hi @milehimikey ! Thank you for the suggestion and sorry for our delay.
We're not looking to implement PlantUML for now. It's a great tool, but users can use Markdown's support for indexing images as much as they need and we think that it will be a better approach for the tool. Supporting PlantUML would require us to find a way to execute a Java dependency, which is out of scope for this project.


Firebase Query ordering respects prev child key.

Firebase Query was accidentally ignoring the second parameter to the
child_added event listener, causing newly added items (after the first
batch of add events) to be added in the wrong order.
/cc @notwaldorf

🚢 🎉


TODO: follow 4.2.0 upgrade

TIP 250: merkle tree root of transaction result

This might be a dangerous decision. since there're only 2 fields in transaction result are used.

Vote for tron power upgrade?

By reading https://github.com/tronprotocol/tips/blob/master/tip-250.md, it seems currently the Tron protocol lacks tampering protection in the block finalization. How would using only 2 fields of the transaction result represent a risk?

The only 2 fields are ret and contract_ret. They and are checked by block's merkle_tree_root, (hash against all txns in the block).
There once was an account_state_root field in Block, which is abandoned.

See-also: https://github.com/tronprotocol/java-tron/pull/3753


Add Maple.Finance

Revision checks

[X] Your Safe App include a manifest.json file at the root with the required data
[X] The app can be loaded as a custom Safe App in the Apps section of https://gnosis-safe.io/app
[X] The app auto-connects to the Safe
[X] You are able to trigger and execute one transaction with a Safe
[X] RPC requests are optimized (not triggering many requests in a very short time period)

Name/Description
Maple Finance
Institutional Crypto-Capital Network
Type

New addition

Compatible Networks
- Mainnet

Code for review
https://github.com/maple-labs/maple-core
IPFS hash/App URL
https://app.maple.finance
Desired date
before 30th May

Hola caballero! I think that the app might not be Rin compatible for now.
Opening the app from https://app.maple.finance/ I can see a prompt to switch to another chain:

plus I am getting a lot of console errors testing it as a safe app:

I suggest we focus on adding it on mainnet only :)

Hey, ah yeah my mistake, we have separate URLs for our testnets and didnt realize that only one url needs to handle the different networks:

https://rinkeby.app.maple.loans/

I'll update the ticket for Mainnet only.

No problem! The mainnet app looks good to me.
I'll hand it over to the devs now to do a check of the code and we should be able to add it to the list before the before 30th May.
Cheers ;)

Thanks, much appreciated

Seems you have some leak in the infura a requests?
https://user-images.githubusercontent.com/1576776/170490983-4efe6cd6-1fd3-4895-bf32-be5a61e23292.mov
I think the ones to https://api.maple.finance/v1/graphql are repeated frequently as well.
The infura ones are important to us because are using our infura key

@Graeme-Code Can you share the code for the frontend ? The one in the description is for the contracts

Another minor thing, when trying to change or disconnect the wallet nothing happen (Not sure if intended)

It's a good thing actually

Seems you have some leak in the infura requests?
Screen.Recording.2022-05-26.at.14.48.00.mov
I think the ones to https://api.maple.finance/v1/graphql are repeated frequently as well.
The infura ones are important to us because are using our infura key

Hi @yagopv thanks for your comments. I'm lead on our offchain team.
Re: the RPC requests, we understand this is a known behavior with Wallet Connect (we're using it under the hood of web3-react).
We've now added a param to prevent polling of the Wallet Connect RPC requests.  As you've noted we do query our API every second that, while this is greater than the block interval, ensures better UX for our users.
I understand the main concern is polling of the RPC since this consumes Infura credits?
This should now be corrected after the initial load, if you might please have another look.

@Graeme-Code Can you share the code for the frontend ? The one in the description is for the contracts
For security our frontend code sits in a private repo.
Happy to answer any specific questions you may have.

Another minor thing, when trying to change or disconnect the wallet nothing happen (Not sure if intended)

Yep this is intended, when app is connected via Gnosis Connector the modal is deactivated. We didn't want people connecting to their signing wallet accidently inside of the safe.

Ok! @Graeme-Code. We spoke internally and not necessary to share the code

Yep this is intended, when app is connected via Gnosis Connector the modal is deactivated. We didn't want people connecting to their signing wallet accidently inside of the safe.

ok!

This should now be corrected after the initial load, if you might please have another look.

About this ... in the https://app.maple.finance I continue to see the requests each second. Did you deploy it to other URL?

Hello, are there any updates? @Graeme-Code

Hey @Graeme-Code, since we haven't received an update for four months, we decided to close the issue. Please feel free to create a new one if you want us to retake a look.


Got memory error when i run  RecastDemo

I built project in "VS2017", there are no errors in build process.  But i got memory error when i run "RecastDemo".

Since I cannot reproduce this I'm going to close the issue. If you can provide steps, please do and reopen the issue.


fix(toolbar): fix mouse hover effect on toolbar icons

Closes #944
Summary
Mousing over icons in Table Toolbar didn't produce hover effect over entire button.
Change List (commits, features, bugs, etc)
src/components/Table/TableToolbar/_table-toolbar.scss
Acceptance Test (how to verify the PR)
Navigate to a Table that has toolbar icons and hover over each to see consistent effect.

:tada: This PR is included in version 2.46.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Adding position:sticky article for #3928

PTAL: @jpmedley

@PaulKinlan Looking at it now. FYI, this is your build error: ERROR: src/content/en/updates/2016/12/position-sticky.md Found sample code block(s) wrapped in ```. Required style is indented by 4 spaces.

@PaulKinlan
Fixed the error while I was there. You should look over all of my changes and make sure you approve.

I approve.


add docs to mvt api schemas

I'm not sure what you mean by docs, but I was planning to add some explanatory content there. Generated a draft. If you meant more technical/financial docs, I'll just open a separate issue for my thing

I want to add missing description for each field within the object schemas
{
      "description": "",
      "name": "side",
      "type": "string"
}

got it, then it's not it


question

Hi
do you have email?
I want to ask some things

Hey @dimiy
Apologies for the late reply. Preferably id like to use github issues as it keeps everything in one place and lets others see any questions and potential solutions we might refer to.
But if its security question related or anything sensitive, you can always find my email permenantley updated here: https://github.com/DreamingRaven/nemesyst/blob/ce44b23f0ee4ba50944caa8c68f83059b6de5b1a/.arch/PKGBUILD#L6

Hey @dimiy since it has been a while I will close this issue. My email is there if you still want it. Happy computing.


how to get the libfreetype version and sourcecode

What are you trying to do?
i have a jdk version  (8.0_202-b08) (build 1.8.0_202-b08)  and i got the shared lib file libfreetype.so.6 in the path jre\lib\amd64
the shared library cause the app crashed
Expected behaviour:
i want to know the version of  libfreetype.so.6 the jdk used or the source code
Observed behaviour:
Any other comments:

@whfjam if it's the shared lib then it's the one your OS provides.  If it's bundled with the JVM then you need to check the source code, look for opnejdk jdk8u on github

I download the jdk from https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u202-b08/OpenJDK8U-jdk_x64_linux_hotspot_8u202b08.tar.gz  then the jdk includes the shared lib  libfreetype.so.6  in path jre\lib\amd64， also it is a debug version，there is no source code in jdk，i had searched alot for this just got the message like “the lib is from where the open jdk was built” ，so it  is not from my OS，and also there is no source code in open jdk

It's version 2.4.0 for that version of Java.  Please note that we no longer support 8_202


Update taxable.rb

make nothing in the "cart" state taxable

I prolly deserve that for writing it in the browser instead of checking it out


Add vertical tab widget to InfluxDB and Telegraf

Integrates the vertical tab widget with the installation pages for InfluxDB and Telegraf. Example:

@kostasb, I had to gulp less to get the formatting to show up properly - as a result, I have some changes to /static/ files that I didn't commit. Should I push those up as well or will the build process take care of it?

@rkuchan The staging website doesn't show up correctly, so I guess it needs the new static artifacts to be committed as well. The build process does not involve npm so it will not detect the changes.
Here is the staging site for this branch:
http://docs.staging.influxdata.com:31003/influxdb/v1.0/introduction/installation/#installation


Adds getStore from rev.eng. search API

Through the stores CSV file from the Vinmonopolet "datadeling"-page, you don't get the store ID, and you cannot resolve from location for instance. This adds a retriever for getting stores by query and/or location.
This way we can add a facet for getting products by store (pull request to come).
Let me know what you think.

I added an explicit endpoint by getting by store, even though this is already kind of supported by using a facet. Reason is I think this could be elevated as an API. I'm not sure if this is the best way and that it should be it's own endpoint. It's more API layer and more to maintain, but also easier to use in case of getting by store. Let me know if I should remove it (or do it as it's own PR)

Thanks! Merged and released as 5.1.0

Brilliant. 👌 Thank you!


unrecognized adapter: consul://localhost:8500

What version of docker are you running?
17.06.2-ce

Description of the problem:
I download the registrator source code and use "go build registrator.go" command to compile target ELF file registrator. When I run "./registrator consul://localhost:8500",error is:"unrecognized adapter: consul://localhost:8500", but consul is running on port 8500. How can i solve this problem？
Thank you verymuch!
Bestwishes!

How did you fix it?

can not remeber，give you source code？


Add warning when CASSANDRA_HOME is set in environment

Solution for Issue340.
If there is CASSANDRA_HOME environment variable, it will be warned.

I am sorry I mistook handling branches and being confused.
I will refine my codes and push tommorw.

Thank you!


docs: Adds required organization argument in lacework provider block

GROW-1372
Summary
When using terraform-aws-cloudtrail-controltower template without "organization" var set to true, the following error will be generated:
│ Error: Error creating AwsCtSqs cloud account integration: │ [POST] https://<tenant>.lacework.net/api/v2/CloudAccounts │ [400] AccountMappingFile or AccountMapping is for Org Level aws CloudTrail Integration only.
The submitted change to our example code includes a provider block that will meet this prerequisite and avoid customers encountering the above error when following our code example. Considering that the purpose of the template stipulates the use of ControlTower, this prerequisite will be true for all feasible use-cases as it is only applicable to org trails.
How did you test this change?
Provided and confirmed solution in customer support issue #10388, associated with https://lacework.atlassian.net/browse/GROW-1372
Issue
Template has dependency of lacework/lacework ~> 1.0 for module and organization boolean must be set to true to provide access to org API features or return the error above. Including the provide block in our example code will avoid customer confusion when using the example.

@GilbertStawny could you also add this block in https://github.com/lacework/terraform-aws-cloudtrail-controltower/blob/main/examples/default/README.md please?

Make it so


Pre-built docker image

Are there any plans to distribute this client on dockerhub? For easy integration into ci pipelines that are docker-based
For my team, we are using gitlab CI, and it looks like to use the sleuth client, we would need to create a custom ci docker image and install sleuth on that.
For organizational reasons, we can't use the native sleuth integration with gitlab itself, so we are trying out the sleuth clinet.

No immediate plans, but I'll make sure it gets added to the backlog for consideration. Another option is to make the Gitlab integration read-only, though that only helps if Gitlab is internet accessible.


is there a --quiet option

For my commit hook, I'd prefer jscs to say nothing if all is well.
Does this already exist?

@mikesherov, still, it would be handy to have a --quiet option that is completely silent upon success. CSSLint is another tool that has such option.
I did not want to use the -r inline option, I'd prefer the more verbose report mode as default is. So that did not do the trick for me.
I tried the grep variant like this:
jscs  code.js | grep -v "No code style errors found."

My problem was that the exit-code was from grep and not from jscs. So I got a exit code of 1 from grep while I expected an exitcode  of 0 from jscs.
I sorted it out using PIPESTATUS (bash) as below shows. It works for me so I can use it like that.
jscs  code.js | grep -v "No code style errors found." ; echo ${PIPESTATUS[0]}

But a --quiet option would perhaps be a more solid solution.

@mosbeth, in 2.0 JSCS will obey the rule of silence.


Refactor IncrementalCompilation to IncrementalCompilationState

Looked over the FIXME comments. Decided to start with a simple task like renaming the IncrementalCompilation class to IncrementalCompilationTests.
Ran the tests and everything looks good on my side.

@swift-ci test

No worries 👍


Absolute poll not allowing space members to vote

Yes they are in my workspace. I am a teacher and they are students and they cannot vote in the poll when I post it to the space.

☺

☺

I know people who are experiencing this too. I think its something related to network blocking.

@slaymaker0724, do your students use different email domains? If so, it could be a known issue, similar to #18. If not, it might be related to network blocking, as suggested by @bl791, or perhaps a Chrome plugin is causing the issue."

@dyaskur The people I know who are experiencing this issue are all using personal (Gmail) accounts. I do not think it is a Chrome extension, but instead a network-level blocking issue. Some networks may block certain websites for certain reasons (ie malware/inappropriate content) and the requests required for this extension may trigger a false positive for the blocking algorithm.

Help

Verify thank you
9731150182
On Wed, Dec 6, 2023, 17:30 guardnow @.***> wrote:

Help
—
Reply to this email directly, view it on GitHub
https://github.com/dyaskur/google-chat-poll/issues/44#issuecomment-1842732526,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BDU5IK5NGOABYSOFZH67YWDYIBM6DAVCNFSM6AAAAAA7GLIJBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBSG4ZTENJSGY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Thanks for the next move

I think whoever is the manager of your school's google workspace puts restrictions on their student's google chat permissions.

—
Reply to this email directly, view it on GitHub
https://github.com/dyaskur/google-chat-poll/issues/44#issuecomment-1891303560,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BFI6DYLY74M5SBITLCK4NFDYOSZNDAVCNFSM6AAAAAA7GLIJBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJRGMYDGNJWGA
.


OpTestPCI: Refactor classes for reuse

Enable the ability for each test to be run based on a subclass
setup.
Enable dynamic comparision of hardboot skiroot to hardboot host os
and softboot skiroot to softboot host os.
Add a pci-regression suite which performs full coverage.
Signed-off-by: Deb McLemore<EMAIL_ADDRESS>

retest this please

retest this please

retest this please


Installing libutil after failing a cargo build results in missing headers

Observed Behaviour
On Ubuntu 20.04 installing sudo apt install libutil-freebsd-dev after trying to run cargo build resulted in a long error containing the following:
ld.lld: error: undefined symbol: pidfile_open
My guess is that the cargo build process was not failing early enough so it thought that pidfile-rs was successfully installed despite the missing header files (libutil was not installed on the first cargo build).
Expected Behaviour
It would be helpful if this could fail earlier in the build process so that cargo doesn't assume a successful build of pidfile-rs when libutil is missing.
Work Arounds
If anyone else encounters this issue the solution is to install libutil-freebsd-dev and then run cargo clean -p pidfile-rs. After that your builds should succeed.

I think it’s worth noting that at the moment the only implementation really supported is that in libbsd, as it provides a pkg-config file. To be fair, I’m a bit surprised something worked at all in your case — but re-checking the code it seems I never use the result of the pkg-config check :slightly_smiling_face:

haha! Yeah, can confirm it looks like the pidfile checks are working as expected. Yay, unexpected functionality! :laughing:

So it's my first time using either libbsd or libutil is there any major differences that I cause issue later or is it essentially a re-packaging of the same thing?

As far as I understand, libbsd is a portable version of utility functions from *BSD systems, while libutil-freebsd-dev is a package providing the original library with all original semantics (including the header names and the lack of pkg-config).

Sorry, not being a C++ developer that distinction is going a little over my head atm but it sounds like this is the officially supported library I want yeah?
https://packages.ubuntu.com/focal/libbsd-dev

Yes, you want to install libbsd-dev on Debian or Ubuntu to get this to work.

Awesome, I'll update my stuff. Thanks @andrewshadura !


[Question] Properties set for ILuisModel are not taken into account

System Information (Required)

SDK Language: .NET/C#
SDK Version: <IP_ADDRESS>
Development Environment: LOCALHOST + ngrok

Issue Description
After update to Bot.Builder 3.8.2:
If you create Luis Service this way:
new LuisService(new LuisModelAttribute("id","key") { Verbose = true})
your uri to luis won't take Verbose into account, and your url will be like:
https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/x?subscription-key=y&q=query&log=True
instead of:
https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/x?subscription-key=y&verbose=true&q=query&log=True
Expected Behavior
https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/x?subscription-key=y&verbose=true&q=query&log=True
url should be created
Actual Results
https://westus.api.cognitive.microsoft.com/luis/v2.0/apps/x?subscription-key=y&q=query&log=True url has been created

@shather can you please add more code so we can try to help you further.
Neither the LuisService  nor the LuisModelAttribute  havethe Verbose property.  However the LuisRequest has this property.  I may be missing something so i would like to see more of your code if possible
another thing I tried that seemed to help was manually adding the query string via             var x =             new LuisService(new LuisModelAttribute("eb7500a1-8134-4904-87ef-5b0a026de304", "e24b3becca7e445ea16cc3ce74d45cb9"));             x.BuildUri("add_to_querystring");

Closing this issue due to lack of response.


SDK documentation

I'm still a newbie. I tried to use this SDK but I failed because I couldn't find a proper documentation for it. So I tried to generate a documentation using typedoc but I got ton on errors.
May you please guide me how to learn it in the proper way?
tests/services/AdminService.spec.ts:82:77 - error TS2705: An async function or method in ES5/ES3 requires the 'Promise' constructor.  Make sure you have a declaration for the 'Promise' constructor or include 'ES2015' in your '--lib' option.

82         it('Should delete the AuthStore admin model on matching delete id', async function() {
                                                                               ~~~~~

tests/services/AdminService.spec.ts:96:9 - error TS2582: Cannot find name 'it'. Do you need to install type definitions for a test runner? Try `npm i --save-dev @types/jest` or `npm i --save-dev @types/mocha`.

96         it('Should not delete the AuthStore admin model on mismatched delete id', async function() {
           ~~

tests/services/AdminService.spec.ts:96:83 - error TS2705: An async function or method in ES5/ES3 requires the 'Promise' constructor.  Make sure you have a declaration for the 'Promise' constructor or include 'ES2015' in your '--lib' option.

96         it('Should not delete the AuthStore admin model on mismatched delete id', async function() {
                                                                                ~~~~~

tests/services/AdminService.spec.ts:111:5 - error TS2582: Cannot find name 'describe'. Do you need to install type definitions for a test runner? Try `npm i --save-dev @types/jest` or `npm i --save-dev @types/mocha`.

111     describe('authWithPassword()', function() {
        ~~~~~~~~

tests/services/AdminService.spec.ts:112:9 - error TS2582: Cannot find name 'it'. Do you need to install type definitions for a test runner? Try `npm i --save-dev @types/jest` or `npm i --save-dev @types/mocha`.

112         it('Should auth an admin by its email and password', async function() {
            ~~

tests/services/AdminService.spec.ts:112:62 - error TS2705: An async function or method in ES5/ES3 requires the 'Promise' constructor.  Make sure you have a declaration for the 'Promise' constructor or include 'ES2015' in your '--lib' option.

112         it('Should auth an admin by its email and password', async function() {
                                                                 ~~~~~

tests/services/AdminService.spec.ts:134:5 - error TS2582: Cannot find name 'describe'. Do you need to install type definitions for a test runner? Try `npm i --save-dev @types/jest` or `npm i --save-dev @types/mocha`.

134     describe('authRefresh()', function() {
        ~~~~~~~~

tests/services/AdminService.spec.ts:135:9 - error TS2582: Cannot find name 'it'. Do you need to install type definitions for a test runner? Try `npm i --save-dev @types/jest` or `npm i --save-dev @types/mocha`.

@mbnoimi Most of the time the README should be enough to guide you. It also incldes all available services with a short explanation what each do - https://github.com/pocketbase/js-sdk#definitions.
Additionally, you can find "copy-paste" examples in the API preview of the PokcetBase Admin UI for your collection, for example:
.
You can still try generating documentation using typedoc, but you need to exclude the tests directory.


Add support for copying path from FolderNode

Fixes #4

Done. Updated VSIX on the gallery as well (version 1.0.12: https://visualstudiogallery.msdn.microsoft.com/81783181-c948-489f-a434-10603e3825bd)