fix *_RUNTIME_LINKING logic

Original pull request by Fabio Rossi (Bitbucket: efferre79, GitHub: efferre79).

corrected the logic otherwise linkage to simage lib is done with SIMAGE_RUNTIME_LINKING is false

Original comment by Fabio Rossi (Bitbucket: efferre79, GitHub: efferre79).

I have just seen all the *_RUNTIME_LINKING flags. Maybe I am missing something… Given the name of those variables, when one is true than the coin library should be dynamically linked to the respective external library.

Original comment by Fabio Rossi (Bitbucket: efferre79, GitHub: efferre79).

With the proposed patch I get the following errors (FREETYPE_RUNTIME_LINKING is the only problematic flag in the group) :
In file included from /var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/glue/freetype.h:99:0,
                 from /var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:54:
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_NONE’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:217:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_NONE, 0, 0, 0, 0),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:768:17: note: previous declaration ‘FT_Encoding_ FT_ENCODING_NONE’
     FT_ENC_TAG( FT_ENCODING_NONE, 0, 0, 0, 0 ),
                 ^
/usr/include/freetype2/freetype/freetype.h:614:11: note: in definition of macro ‘FT_ENC_TAG’
           value = ( ( (FT_UInt32)(a) << 24 ) |  \
           ^~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_MS_SYMBOL’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:219:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_MS_SYMBOL,  's', 'y', 'm', 'b'),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:770:17: note: previous declaration ‘FT_Encoding_ FT_ENCODING_MS_SYMBOL’
     FT_ENC_TAG( FT_ENCODING_MS_SYMBOL, 's', 'y', 'm', 'b' ),
                 ^
/usr/include/freetype2/freetype/freetype.h:614:11: note: in definition of macro ‘FT_ENC_TAG’
           value = ( ( (FT_UInt32)(a) << 24 ) |  \
           ^~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_UNICODE’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:220:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_UNICODE,    'u', 'n', 'i', 'c'),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:771:17: note: previous declaration ‘FT_Encoding_ FT_ENCODING_UNICODE’
     FT_ENC_TAG( FT_ENCODING_UNICODE,   'u', 'n', 'i', 'c' ),
                 ^
/usr/include/freetype2/freetype/freetype.h:614:11: note: in definition of macro ‘FT_ENC_TAG’
           value = ( ( (FT_UInt32)(a) << 24 ) |  \
           ^~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_MS_SJIS’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:222:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_MS_SJIS,    's', 'j', 'i', 's'),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:781:5: note: previous declaration ‘FT_Encoding_ FT_ENCODING_MS_SJIS’
     FT_ENCODING_MS_SJIS    = FT_ENCODING_SJIS,
     ^~~~~~~~~~~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_MS_GB2312’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:223:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_MS_GB2312,  'g', 'b', ' ', ' '),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:782:5: note: previous declaration ‘FT_Encoding_ FT_ENCODING_MS_GB2312’
     FT_ENCODING_MS_GB2312  = FT_ENCODING_PRC,
     ^~~~~~~~~~~~~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_MS_BIG5’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:224:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_MS_BIG5,    'b', 'i', 'g', '5'),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:783:5: note: previous declaration ‘FT_Encoding_ FT_ENCODING_MS_BIG5’
     FT_ENCODING_MS_BIG5    = FT_ENCODING_BIG5,
     ^~~~~~~~~~~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_MS_WANSUNG’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:225:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_MS_WANSUNG, 'w', 'a', 'n', 's'),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:784:5: note: previous declaration ‘FT_Encoding_ FT_ENCODING_MS_WANSUNG’
     FT_ENCODING_MS_WANSUNG = FT_ENCODING_WANSUNG,
     ^~~~~~~~~~~~~~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_MS_JOHAB’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:226:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_MS_JOHAB,   'j', 'o', 'h', 'a'),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:785:5: note: previous declaration ‘FT_Encoding_ FT_ENCODING_MS_JOHAB’
     FT_ENCODING_MS_JOHAB   = FT_ENCODING_JOHAB,
     ^~~~~~~~~~~~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_ADOBE_STANDARD’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:228:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_ADOBE_STANDARD, 'A', 'D', 'O', 'B'),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:787:17: note: previous declaration ‘FT_Encoding_ FT_ENCODING_ADOBE_STANDARD’
     FT_ENC_TAG( FT_ENCODING_ADOBE_STANDARD, 'A', 'D', 'O', 'B' ),
                 ^
/usr/include/freetype2/freetype/freetype.h:614:11: note: in definition of macro ‘FT_ENC_TAG’
           value = ( ( (FT_UInt32)(a) << 24 ) |  \
           ^~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_ADOBE_EXPERT’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:229:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_ADOBE_EXPERT,   'A', 'D', 'B', 'E'),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:788:17: note: previous declaration ‘FT_Encoding_ FT_ENCODING_ADOBE_EXPERT’
     FT_ENC_TAG( FT_ENCODING_ADOBE_EXPERT,   'A', 'D', 'B', 'E' ),
                 ^
/usr/include/freetype2/freetype/freetype.h:614:11: note: in definition of macro ‘FT_ENC_TAG’
           value = ( ( (FT_UInt32)(a) << 24 ) |  \
           ^~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_ADOBE_CUSTOM’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:230:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_ADOBE_CUSTOM,   'A', 'D', 'B', 'C'),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:789:17: note: previous declaration ‘FT_Encoding_ FT_ENCODING_ADOBE_CUSTOM’
     FT_ENC_TAG( FT_ENCODING_ADOBE_CUSTOM,   'A', 'D', 'B', 'C' ),
                 ^
/usr/include/freetype2/freetype/freetype.h:614:11: note: in definition of macro ‘FT_ENC_TAG’
           value = ( ( (FT_UInt32)(a) << 24 ) |  \
           ^~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_ADOBE_LATIN_1’
                       (FT_UInt32)(d)         )
                                              ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:231:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_ADOBE_LATIN_1,  'l', 'a', 't', '1'),
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:790:17: note: previous declaration ‘FT_Encoding_ FT_ENCODING_ADOBE_LATIN_1’
     FT_ENC_TAG( FT_ENCODING_ADOBE_LATIN_1,  'l', 'a', 't', '1' ),
                 ^
/usr/include/freetype2/freetype/freetype.h:614:11: note: in definition of macro ‘FT_ENC_TAG’
           value = ( ( (FT_UInt32)(a) << 24 ) |  \
           ^~~~~
/usr/include/freetype2/freetype/freetype.h:617:46: error: redeclaration of ‘FT_ENCODING_APPLE_ROMAN’
                       (FT_UInt32)(d)         )
                                             ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:235:3: note: in expansion of macro ‘FT_ENC_TAG’
   FT_ENC_TAG(FT_ENCODING_APPLE_ROMAN, 'a', 'r', 'm', 'n')
   ^~~~~~~~~~
/usr/include/freetype2/freetype/freetype.h:794:17: note: previous declaration ‘FT_Encoding_ FT_ENCODING_APPLE_ROMAN’
     FT_ENC_TAG( FT_ENCODING_APPLE_ROMAN, 'a', 'r', 'm', 'n' )
                 ^
/usr/include/freetype2/freetype/freetype.h:614:11: note: in definition of macro ‘FT_ENC_TAG’
           value = ( ( (FT_UInt32)(a) << 24 ) |  \
           ^~~~~
In file included from /usr/include/freetype2/freetype/fttypes.h:26:0,
                 from /usr/include/freetype2/freetype/freetype.h:34,
                 from /var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/glue/freetype.h:99,
                 from /var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:54:
/usr/include/freetype2/freetype/ftimage.h:673:50: error: redeclaration of ‘FT_GLYPH_FORMAT_NONE’
                       (unsigned long)_x4         )
                                                  ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:248:3: note: in expansion of macro ‘FT_IMAGE_TAG’
   FT_IMAGE_TAG( FT_GLYPH_FORMAT_NONE, 0, 0, 0, 0 ),
   ^~~~~~~~~~~~
/usr/include/freetype2/freetype/ftimage.h:717:19: note: previous declaration ‘FT_Glyph_Format_ FT_GLYPH_FORMAT_NONE’
     FT_IMAGE_TAG( FT_GLYPH_FORMAT_NONE, 0, 0, 0, 0 ),
                   ^
/usr/include/freetype2/freetype/ftimage.h:670:11: note: in definition of macro ‘FT_IMAGE_TAG’
           value = ( ( (unsigned long)_x1 << 24 ) | \
           ^~~~~
/usr/include/freetype2/freetype/ftimage.h:673:50: error: redeclaration of ‘FT_GLYPH_FORMAT_COMPOSITE’
                       (unsigned long)_x4         )
                                                  ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:250:3: note: in expansion of macro ‘FT_IMAGE_TAG’
   FT_IMAGE_TAG( FT_GLYPH_FORMAT_COMPOSITE, 'c', 'o', 'm', 'p' ),
   ^~~~~~~~~~~~
/usr/include/freetype2/freetype/ftimage.h:719:19: note: previous declaration ‘FT_Glyph_Format_ FT_GLYPH_FORMAT_COMPOSITE’
     FT_IMAGE_TAG( FT_GLYPH_FORMAT_COMPOSITE, 'c', 'o', 'm', 'p' ),
                   ^
/usr/include/freetype2/freetype/ftimage.h:670:11: note: in definition of macro ‘FT_IMAGE_TAG’
           value = ( ( (unsigned long)_x1 << 24 ) | \
           ^~~~~
/usr/include/freetype2/freetype/ftimage.h:673:50: error: redeclaration of ‘FT_GLYPH_FORMAT_BITMAP’
                       (unsigned long)_x4         )
                                                  ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:251:3: note: in expansion of macro ‘FT_IMAGE_TAG’
   FT_IMAGE_TAG( FT_GLYPH_FORMAT_BITMAP,    'b', 'i', 't', 's' ),
   ^~~~~~~~~~~~
/usr/include/freetype2/freetype/ftimage.h:720:19: note: previous declaration ‘FT_Glyph_Format_ FT_GLYPH_FORMAT_BITMAP’
     FT_IMAGE_TAG( FT_GLYPH_FORMAT_BITMAP,    'b', 'i', 't', 's' ),
                   ^
/usr/include/freetype2/freetype/ftimage.h:670:11: note: in definition of macro ‘FT_IMAGE_TAG’
           value = ( ( (unsigned long)_x1 << 24 ) | \
           ^~~~~
/usr/include/freetype2/freetype/ftimage.h:673:50: error: redeclaration of ‘FT_GLYPH_FORMAT_OUTLINE’
                       (unsigned long)_x4         )
                                                  ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:252:3: note: in expansion of macro ‘FT_IMAGE_TAG’
   FT_IMAGE_TAG( FT_GLYPH_FORMAT_OUTLINE,   'o', 'u', 't', 'l' ),
   ^~~~~~~~~~~~
/usr/include/freetype2/freetype/ftimage.h:721:19: note: previous declaration ‘FT_Glyph_Format_ FT_GLYPH_FORMAT_OUTLINE’
     FT_IMAGE_TAG( FT_GLYPH_FORMAT_OUTLINE,   'o', 'u', 't', 'l' ),
                   ^
/usr/include/freetype2/freetype/ftimage.h:670:11: note: in definition of macro ‘FT_IMAGE_TAG’
           value = ( ( (unsigned long)_x1 << 24 ) | \
           ^~~~~
/usr/include/freetype2/freetype/ftimage.h:673:50: error: redeclaration of ‘FT_GLYPH_FORMAT_PLOTTER’
                       (unsigned long)_x4         )
                                                  ^
/var/tmp/portage/media-libs/coin-9999/work/Coin-9999/src/fonts/freetype.cpp:253:3: note: in expansion of macro ‘FT_IMAGE_TAG’
   FT_IMAGE_TAG( FT_GLYPH_FORMAT_PLOTTER,   'p', 'l', 'o', 't' )
   ^~~~~~~~~~~~
/usr/include/freetype2/freetype/ftimage.h:722:19: note: previous declaration ‘FT_Glyph_Format_ FT_GLYPH_FORMAT_PLOTTER’
     FT_IMAGE_TAG( FT_GLYPH_FORMAT_PLOTTER,   'p', 'l', 'o', 't' )
                   ^
/usr/include/freetype2/freetype/ftimage.h:670:11: note: in definition of macro ‘FT_IMAGE_TAG’
           value = ( ( (unsigned long)_x1 << 24 ) | \
           ^~~~~
make[2]: *** [src/fonts/CMakeFiles/fonts.dir/build.make:111: src/fonts/CMakeFiles/fonts.dir/freetype.cpp.o] Error 1
make[2]: Leaving directory '/var/tmp/portage/media-libs/coin-9999/work/coin-9999_build'
make[1]: *** [CMakeFiles/Makefile2:1108: src/fonts/CMakeFiles/fonts.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Original comment by Volker Enderlein (Bitbucket: VolkerEnderlein, GitHub: VolkerEnderlein).

Hi Fabio,
it's just the other way round. *_RUNTIME_LINKING means to load the dynamic libraries (DLL's, shared objects) at runtime. See how the ZLIB_RUNTIME_LINKING #define is used in the coin\src\glue\zlib.cpp source file.
If it is set to OFF, you need to provide either static or dynamic zlib libraries at build time.
Cheers Volker

Original comment by Fabio Rossi (Bitbucket: efferre79, GitHub: efferre79).

Hi Volker,
I have misunderstood the rationale, I was reading *_RUNTIME_LINKING but thinking to load-time linking :slight_smile: I see now that when those flags are OFF the build system looks for system libraries and, if not found, eventually the code may use a static solution. I would like to understand which of those libraries are strictly mandatory for a proper operation of the coin library.

Original comment by Fabio Rossi (Bitbucket: efferre79, GitHub: efferre79).

it seems that I might install coin on a system without spidermonkey (even with VRML enabled) and openal. If simage is not installed and runtime linking is disabled the build completes but I don’t see a static implementation so I assume simage is strictly  required. I guess than the build configuration process should fail when SIMAGE_RUNTIME_LINKING=OFF and simage is not installed.
Probably the same applies also to the other libraries. If runtime linking is disabled then when the library is mandatory or when the relative option is enabled the configuration should fail if the library is not installed. What do you think?

Original comment by Bastiaan Veelo (Bitbucket: veelo, GitHub: veelo).

so I assume simage is strictly required.

simage is not required. It is used for loading image files from common file formats, typically for use in texture mapping. But if you don’t use textures or you generate your textures programatically, you’ll do fine without simage.

Bastiaan.

Original comment by Bastiaan Veelo (Bitbucket: veelo, GitHub: veelo).

I would like to understand which of those libraries are strictly mandatory for a proper operation of the coin library.

I don’t think any of them are.

Original comment by Fabio Rossi (Bitbucket: efferre79, GitHub: efferre79).

Shouldn’t then the build configuration be more flexible adding HAVE_ZLIB, HAVE_BZIP2, etc as for HAVE_SOUND?

Original comment by Bastiaan Veelo (Bitbucket: veelo, GitHub: veelo).

Not necessarily. HAVE_ZLIB and HAVE_BZIP2 are set on lines 210 and 224 respectively, so Coin can leave out functionality that depends on these libraries if they are not available/disabled.
I am not exactly sure though (I haven’t checked the code) but I think they are not mandatory.

EDIT: You mean you want to be able to disable them even though they are available?

Original comment by Fabio Rossi (Bitbucket: efferre79, GitHub: efferre79).

You mean you want to be able to disable them even though they are available?

Right, the point is that you cannot disable them explicitly. They are auto-disabled if not available on the system but if they are present, you cannot remove that functionality. In the worst case you could disable all of them but then I don’t know if coin is still useful :slight_smile:

Original comment by Bastiaan Veelo (Bitbucket: veelo, GitHub: veelo).

The compression libs are used to optionally save/load scene graphs in compressed .iv format. Coin will do fine with uncompressed .iv files and many Coin applications don’t even need to save/load scene graphs at all. IIUC, Coin can currently be configured to link these libraries at run time (the default) in which case the ability to load/save compressed files depends on the presence of these libs on the system that the program is running on. It can also be configured to link at link time, in which case the library needs to be present on the development machine.
True it cannot be disabled, but why would one need that option? If the objective is to reduce binary size, you would also need to instrument the code with additional #ifdefs, not merely tweak build options. That’s a lot of work and I doubt that would be worthwhile.
The details are in src/glue/zlib[.h|.cpp].

Original comment by Bastiaan Veelo (Bitbucket: veelo, GitHub: veelo).

Fabio,
I think the current behaviour is correct and that we should not merge this PR. Would you agree to decline it?
Are you having problems configuring and using Coin with its current options? If so we can try to address those.

Bastiaan.

Original comment by Giampiero Gabbiani (Bitbucket: ggabbiani, GitHub: ggabbiani).

Hi all,

sorry but I’m still missing which kind of problem this PR should solve, if not better specified for me it should be declined.

Regards
Giampiero

Original comment by Fabio Rossi (Bitbucket: efferre79, GitHub: efferre79).

I declined by myself

Original comment by Bastiaan Veelo (Bitbucket: veelo, GitHub: veelo).

Allright, thanks for your intention to improve Coin!


Lazy loading background image on  tag

I got a doubt about how to properly lazy load background images on <body> tag.
For reference, I'm using TailwindCSS framework.
I added the lozad class to the <body> tag and set a background image with gradient overlay by defining a background-image in my stylesheet like this:
body {
  background-image: linear-gradient(to top left, config('colors.gd-primary'), config('colors.gd-secondary')), url('../images/background.jpg');

  @apply .bg-fixed .relative .bg-secondary .bg-cover .bg-center .bg-no-repeat ;
}

The image loads and everything seems fine, however I'm still unsure if the image is lazy loaded and if this is the proper way to work this around. Also read about the data-background-image example on project's README.md so it also makes me wonder if my approach is right.
Is there a better way to do this or is it even working at all?

@rafaaro possible to share a codepen implementation?


Add copy-to-clipboard to add-constrain

Taking over changes from https://github.com/cockroachdb/docs/pull/3278. Thanks to @Kolokodess!

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/93786bad87558e49d2258bda0d449455a3a22637/


Redirect of panic (via unix.Dup2) not working after DoT resolve

I found a weird bug, do you have any idea what may causes this?
main.go:
package main

import (
	"fmt"
	"log"
	"net"
	"os"

	dns "github.com/ncruces/go-dns"
	"golang.org/x/sys/unix"
)

func hasArg(val string) bool {
	for _, argI := range os.Args[1:] {
		if val == argI {
			return true
		}
	}
	return false
}

func LogStderrToFile(dstFile string) {
	f, err := os.OpenFile(dstFile, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0666)
	if err != nil {
		log.Fatalf("OpenFile failed: %v", err)
	}

	err = unix.Dup2(int(f.Fd()), int(os.Stderr.Fd()))
	if err != nil {
		log.Fatalf("Dup2 failed: %v", err)
	}

	os.Stderr = f

	if hasArg("also-redirect-log") {
		log.SetOutput(f)
	}
}

func main() {
	path := "/tmp/test.log"
	fmt.Printf("redirect stderr to: %s\n", path)
	LogStderrToFile(path)

	if hasArg("DoT") {
		resolver, err := dns.NewDoTResolver("cloudflare-dns.com", dns.DoTAddresses("<IP_ADDRESS>", "<IP_ADDRESS>"), dns.DoTCache())
		if err != nil {
			panic(err)
		}
		net.DefaultResolver = resolver
	}

	addrs, _ := net.LookupHost("www.wikipedia.org")
	fmt.Printf("addrs: %v\n", addrs)

	panic("test")
}

Results:
$ go run main.go; echo --; cat /tmp/test.log
redirect stderr to: /tmp/test.log
addrs: [2a02:ec80:300:ed1a::1 <IP_ADDRESS>]
exit status 2
--
panic: test

goroutine 1 [running]:
main.main()
	/src/main.go:56 +0x1a5

$ go run main.go also-redirect-log; echo --; cat /tmp/test.log
redirect stderr to: /tmp/test.log
addrs: [2a02:ec80:300:ed1a::1 <IP_ADDRESS>]
exit status 2
--
panic: test

goroutine 1 [running]:
main.main()
	/src/main.go:56 +0x1a5

$ go run main.go DoT; echo --; cat /tmp/test.log
redirect stderr to: /tmp/test.log
addrs: [2a02:ec80:300:ed1a::1 <IP_ADDRESS>]
exit status 2
--
panic: test

goroutine 1 [running]:
main.main()
	/src/main.go:56 +0x1a5

$ go run main.go also-redirect-log DoT; echo --; cat /tmp/test.log
redirect stderr to: /tmp/test.log
addrs: [2a02:ec80:300:ed1a::1 <IP_ADDRESS>]
exit status 2
--

$

So when using both also-redirect-log (log.SetOutput) and DoT (NewDoTResolver), the panic is not logged to the file.

No. No idea.

It doesn't happen when using the default resolver, though - Weird
Are you able to reproduce it? I use go1.21.4
Will you have any time/desire to investigate this? Do you think it could be a bug in the go runtime somehow?

No, I can't reproduce it.
$ go version
go version go1.21.4 darwin/amd64

Hm, I tested it in another linux environment: go version go1.19.5 linux/amd64
In there go run main.go also-redirect-log DoT also generates an empty /tmp/test.log file.
So I guess it is linux only. Do you by any chance have a linux system you could test this with?
In case this library is not doing anything "low level" regarding logging / file handle manipulation, it must come from golang.org/x/net, as that is the only dependency used here, right?

That dependency is a test dependency only.
And no, the library is not doing anything weird.

Got resolved - It was due to garbage collection of the overwritten os.Stderr (see https://github.com/golang/go/issues/64555#issuecomment-1842115871)


Painter redesign

This PR redisgns the automobile painter to have a better UI and update the automobile color directly. Punch an automobile and and the painter formspec comes up initialized with the automobile's color. Move the sliders or manually enter a hex code. Press set color and the automobile's color is updated. Only the owner can paint an automobile.

The problem is that will do not work with the airplanes, as it turned specific for the cars. And I want to keep painting my planes with more interesting colors :)

@APercy I will try adding _on_paint hooks to everything later.

@APercy I changed the painter so it can work with any entity that has a _change_color hook.  Hopefully I got all of them.

perfect! I added the same code to the trike and it worked like a charm

Oops! I guess I forgot to make a PR for the trike. I even forked and modified it.

relax, I did it myself yesterday :)


added schema validation

This PR updates the validation done by the package by using the (only) python based openapi schema validator.
Aside from being agreed upon in the discussion - this is necessary for handling of oneOf, allOf etc., because the preexisting validation needs to be thoroughly reworked - so its simpler to simply strip it away first.
current state -
ready for being merged - pointing at my previous PR

I've now updated the v3 branch where I rename the source directory and the package name to django-openapi-tester. Unfortunately this creates an enormous amount of conflicts, so I think the best thing to do might be to re-apply the changes here (unless you're a git wizard and know of a better solution). Let me know if you need help.
I think I'll merge v3 tonight, and make any further changes in a new separate branch so we're not depending on each other.

I've now updated the v3 branch where I rename the source directory and the package name to django-openapi-tester. Unfortunately this creates an enormous amount of conflicts, so I think the best thing to do might be to re-apply the changes here (unless you're a git wizard and know of a better solution). Let me know if you need help.
I think I'll merge v3 tonight, and make any further changes in a new separate branch so we're not depending on each other.

I've now updated the v3 branch where I rename the source directory and the package name to django-openapi-tester. Unfortunately this creates an enormous amount of conflicts, so I think the best thing to do might be to re-apply the changes here (unless you're a git wizard and know of a better solution). Let me know if you need help.
I think I'll merge v3 tonight, and make any further changes in a new separate branch so we're not depending on each other.

@sondrelg  yes i can resolve these, but you need to revert your merge to master. You basically wrote me out of the git blame record. I assume it was unintentional, but its not acceptable for me - when i do work I expect it to clearly appear I have done that.

I've now updated the v3 branch where I rename the source directory and the package name to django-openapi-tester. Unfortunately this creates an enormous amount of conflicts, so I think the best thing to do might be to re-apply the changes here (unless you're a git wizard and know of a better solution). Let me know if you need help.
I think I'll merge v3 tonight, and make any further changes in a new separate branch so we're not depending on each other.

@sondrelg  yes i can resolve these, but you need to revert your merge to master. You basically wrote me out of the git blame record. I assume it was unintentional, but its not acceptable for me - when i do work I expect it to clearly appear I have done that.

I see. Yep not intentional - I'll try to revert :)

I see. Yep not intentional - I'll try to revert :)

Done 👍

Done 👍

Done 👍

much obliged.

Done 👍

much obliged.


[devicelab] reduce iterations, uninstall at end, and use  --application-binary in all startup tests

Description
These devicelab tests are incredibly flaky. Currently they will build & install the same application 15 times. This causes the temp storage to fill up on android, and has a good chance of flaking on iOS due to install issues.
The change from 3 to 15 increased total test time for 2 -> 12 minutes on iOS, or roughly 5 more test equivalents for every single iOS test. Reduce the iteration count back to 5
Uninstall the app after each run so temp storage does not fill up.

if it needs to be 15, then it should be restricted to one important test case. Right now this effects 11 tests, so its a large resource increase to the devicelab

All start_up tests seem to be quite noisy to me, and they're of similar importance. I think the best way forward is to reduce the iteration time so we can do a startup iteration in ~10 second so maybe we can do 50 iterations to further reduce the noise without deplete the device lab.

We're never going to be able to do an iteration in 10 seconds

For fun I ran this change on an iPhone 6 with 15 iterations and it reduced complex_layout_ios__start_up from 6:47 to 43 seconds.

Additionally, even if our launch was 99% reliable, running it 50 times would mean that at least one run would fail about 40% of the time.

For fun I ran this change on an iPhone 6 with 15 iterations and it reduced complex_layout_ios__start_up from 6:47 to 43 seconds.

This looks promising. If I understand it correctly, this is 2.87 seconds / iteration which is much faster than my 10 seconds / iteration goal?

Additionally, even if our launch was 99% reliable, running it 50 times would mean that at least one run would fail about 40% of the time.

We could write the benchmark in a way to ignore a certain proportion of failures and only use the successful ones to compute the average. But as a developer, I'd really love to increase the reliability as much as possible (e.g., flutter run should retry certain fragile steps to make the whole command fail less often). The 1% failure may still cost a developer headaches and loss of time.


Enhanceadd default order by of non-order query for original planner

Proposed changes
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[x] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[x] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall

run p0

run buildall

run buildall

run p0

run p0

run p0

run buildall

maybe we should do this rewrite after do single node plan. to cover this case:
select c1, c2, c3 from (select * from t) t2 limit 100, 10;

run buildall


Symfony CLI version command shows current time as build date

Describe the bug
After installing symfony-cli you can run symfony version. This command prints something like:
Symfony CLI version 5.8.17 (c) 2021-2024 Fabien Potencier (2024-05-13T12:16:30+02:00 - stable)
Usually the date at the end is the build date. But when installed via nix it always shows the current time, so the command output is different for every second.
The build date is passed here:
https://github.com/symfony-cli/symfony-cli/blob/870a3ce2ccaa6428f83428e204231b0c9be9b698/main.go#L126
It also has a comment saying overridden at linking time:
https://github.com/symfony-cli/symfony-cli/blob/870a3ce2ccaa6428f83428e204231b0c9be9b698/main.go#L43-L44
Steps To Reproduce
Steps to reproduce the behavior:

Install symfony-cli: https://search.nixos.org/packages?channel=unstable&show=symfony-cli&from=0&size=50&sort=relevance&type=packages&query=symfony-cli
Run symfony version

Expected behavior
It should show the real build time of that release (time of last commit?).
Notify maintainers
@drupol

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.5.0-28-generic, Linux Mint, 21.3 (Virginia), nobuild`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.22.0`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/home/rafael/.nix-defexpr/channels/nixpkgs`

Add a :+1: reaction to issues you find important.

Hello,
Is this really a problem?
If you really want to fix it, it is possible to add: "-X main.buildDate=<something>" in here with a fixed date value or possibly the date of the commit tag.

@drupol Awesome, thanks for taking the time to implement this!


Progress bar always show 100 percentage or inconsistent when uploading to localhost

Use case 1: when trying to upload single file (around ~ 4MB and even more) to the localhost server, it shows 100 % progress bar value although file upload is not completed
Use case 2: when I try same code base on the AWS server shows correctly the progress bar
What and where could be the problem?
Thanks!

Transferring file on local machine network is fast and almost instant, so that's why you see 100 right away. Try a 1 GB file and you will see the progress.


fix: use original resource kind as result.spec.kind

Closes k8sgpt-ai/k8sgpt-operator#240
📑 Description
this is one approach to fix k8sgpt-ai/k8sgpt-operator#240 by using the original analyzed resource kind for the result.spec.kind attribute.
✅ Checks

[ ] My pull request adheres to the code style of this project
[ ] My code requires changes to the documentation
[ ] I have updated the documentation as required
[ ] All the tests have passed

ℹ Additional Information

unfortunately with this change the prompt for ConfigAuditReport and VulnerabilityReport is again default since the Kind is used to set another prompt ... https://github.com/k8sgpt-ai/k8sgpt/blob/1da4b7c8f0eee877d5b76a7dd9abda7631d922f3/pkg/analysis/analysis.go#L266
will have a look

@thschue unfortunatly not because of https://github.com/k8sgpt-ai/k8sgpt/pull/678#issuecomment-1729566846

I need to create a new PR where the kind is still „ConfigAuditReport“ and the name is the name of the ConfigAuditReport

close this one because https://github.com/k8sgpt-ai/k8sgpt/pull/869 is a better approach


SPI tokenfetcher early draft

What does this PR do?
Screenshot/screencast of this PR

What issues does this PR fix or reference?

How to test this PR?

We need some way for the code that will use GetFileContents to provide a name if the namespace where the SPI should look for a SPI's tokens.


Rename http://childes.psy.cmu.edu to https://childes.talkbank.org

Resolve https://github.com/nltk/nltk/issues/2237

Thanks @FranklinChen!


default to stripping eBPF object files

What does this PR do?
Uses llvm-strip -g to strip eBPF object files of unnecessary DWARF information.
Motivation
potentially save 36MiB in package size, due to smaller object files. (77MiB before - 41MiB after)
Additional Notes
debian 10 failing, waiting for #19030
Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

Nevermind, this is already being done in CI.


A typo in readme.md?

Hello.
I believe, there is a mistake in the description of regular modifier. It now reads:

strong::regular. Same as regular and also equality comparable. A good default base for most types.

It probably should say  : Same as *semiregular*... ?

Yes. Thanks! Fixed


doc: outline design for OCSP revocation

This issue outlines how the core revocation functionality will be built into notation-core-go, and how it will be integrated with notation-go. This additional functionality will provide a mechanism to check the revocation status of certificates in a way that can be easily integrated into other projects, and to conduct revocation checks as part of the Verify process.
These changes will address the following issue:

Implement OCSP Support (https://github.com/notaryproject/notation-core-go/issues/124)

CRL Support will not be implemented until later.
The outlined mechanisms are based upon previously defined specifications (https://github.com/notaryproject/notaryproject/blob/main/specs/trust-store-trust-policy.md#certificate-revocation-evaluation) as well as some ideas from existing solutions (https://pkg.go.dev/github.com/cloudflare/cfssl/revoke and https://github.com/grpc/grpc-go/blob/52ca9571068d/security/advancedtls/crl.go) that don’t fully match our use case.
Implementation is planned to be completed in two PRs. The first will introduce the revocation package in notation-core-go. The second PR will follow, which will incorporate the revocation package into notation-go. These sections are separated by a horizontal line.

Notation-core-go
The following will be added as a new package within the x509 package via a new file, revocation.go:
// Internal struct
type revocation struct {
    httpClient            *http.Client
    ocspTimeoutThreshold  time.Duration
}

// Options struct
// Users can specify any options they want for constructing a revocation object
// If an option is unspecified or nil, a default value will be assigned in the NewRevocation function
type RevocationOptions struct {
    ocspTimeoutThreshold  time.Duration
}

// Constructor to return a revocation object that substitutes default values for any that are passed as nil
func NewRevocation(httpClient *http.Client, options RevocationOptions) *revocation

// Errors:
// RevokedInOCSPError is returned when the certificate's status for OCSP is ocsp.Revoked (or ocsp.Unknown?)
type RevokedInOCSPError struct{}
func (e RevokedInOCSPError) Error() string {
    return "certificate is revoked via OCSP"
}

// CheckOCSPError is returned when there is an error during the OCSP revocation check, not necessarily a revocation
type CheckOCSPError struct {
    Err error
}
func (e CheckOCSPError) Error() string {
    if e.Err != nil {
        return fmt.Sprintf("error checking revocation via OCSP: %s", e.Err.Error())
    } else {
        return "error checking revocation via OCSP"
    }
}

// NoOCSPServerError is returned when the OCSPServer is not specified or is not an HTTP URL.
type NoOCSPServerError struct{}
func (e NoOCSPServerError) Error() string {
    return "no valid OCSPServer found"
}

// OCSPTimeoutError is returned when the connection attempt to a OCSP URL exceeds the specified threshold
type OCSPTimeoutError struct{}
func (e OCSPTimeoutError) Error() string {
    return "exceeded timeout threshold for OCSP check"
}

// It may be necessary to add other errors to the ones specified as new errors/results are discovered during development

// Methods:
// Checks OCSP, then CRL status, returns nil if all certs in the chain are not revoked
// If any are revoked, it will return one of the defined errors in this file
// If there is some other error, it will return that error
// NOTE: Will only perform OCSP until CRL is implemented
func (r *revocation) Validate(certChain []*x509.Certificate) (error)

// Only checks OCSP, same returns as above
func (r *revocation) OCSPStatus(certChain []*x509.Certificate) (error)

Since testing this will require validating against OCSP server responses, a mock client needs to be created to mock these responses. This will be added to the testhelper package in a new file named httptest.go:
// Creates a mock HTTP Client (more accurately, a spy) that intercepts requests to /issuer and /ocsp endpoints
// The client's responses are dependent on the cert and desiredOCSPStatus
func MockClient(cert *x509.Certificate, key *rsa.PrivateKey, desiredOCSPStatus ocsp.ResponseStatus) *http.Client

In addition to the mocked client, we will also need a new test certificate that specifies an OCSPServer in the certificate template. This value will be necessary to confirm revocation status with the mocked client. The following will be added to the testhelper package in the existing certificatetest.go file:
var revokableRSALeaf RSACertTuple

// GetRevokableRSALeafCertificate returns leaf certificate that specifies a local OCSPServer signed using RSA algorithm
func GetRevokableRSALeafCertificate() RSACertTuple

Notation-go
The following will be added/modified in the verifier package within the existing verifier.go file:
// Since a section has already been added to Verify as a placeholder for revocation, it will be modified to incorporate the verifyRevocation function
func (v *verifier) Verify(ctx context.Context, desc ocispec.Descriptor, signature []byte, opts notation.VerifyOptions) (*notation.VerificationOutcome, error)

// The verifyRevocation function will use the revocation.Validate() function defined in notation-core-go to verify the revocation status
func verifyRevocation(outcome *notation.VerificationOutcome) *notation.ValidationResult

TypeRevocation has already been added to the ValidationTypes in the trustpolicy, so no change is needed there.

Thanks @kody-kimberl for the design. I have some open discussions below:

I'm just trying to go through the workflow, so basically, func OCSPStatus() will take in the cert chain and do OCSP check one by one. Inside this func, I suppose we will be creating OCSP requests using<EMAIL_ADDRESS>Such request requires an issuer from the cert via IssuingCertificateURL. IMO, we could have another internal function func ocspRequest() in this design for generating the OCSP requests. (it'll be called from func OCSPStatus())
Do we need the ocspTimeoutThreshold field in type revocation struct? Because a http.Client struct has its built in Timeout field (https://pkg.go.dev/net/http#Client), can we use that direclty?
There are a few Error types defined in revocation.go, I think we could move them to a new file with name errors.go.

Thank @kody-kimberl for sharing the design. Will the revocation implementation in notation-core-go be purely based on the golang built-in crypto library (such as RevocationList.CheckSignatureFrom())?

Thank you for all the great comments!

@patrickzheng200

I'm just trying to go through the workflow, so basically, func OCSPStatus() will take in the cert chain and do OCSP check one by one. Inside this func, I suppose we will be creating OCSP requests using<EMAIL_ADDRESS>Such request requires an issuer from the cert via IssuingCertificateURL. IMO, we could have another internal function func ocspRequest() in this design for generating the OCSP requests. (it'll be called from func OCSPStatus())

I 100% agree. I was planning on having a helper function for generating this request as you mentioned, and I like your name for it. Having this logic separated will allow the requests to be done in parallel for each certificate in the chain.

Do we need the ocspTimeoutThreshold field in type revocation struct? Because a http.Client struct has its built in Timeout field (https://pkg.go.dev/net/http#Client), can we use that direclty?

The reason I included this is to be forward thinking. The specification states that there should be a different timeout for OCSP and CRL. Once we incorporate CRL revocation, we will need an additional timeout option. Thus, I figured it is best to decouple the OCSP timeout from the client initially in order to minimize the changes that will be necessary to add CRL revocation in the future.

There are a few Error types defined in revocation.go, I think we could move them to a new file with name errors.go.

I agree, I'll add this when implementing it.

@shizhMSFT

Will the revocation implementation in notation-core-go be purely based on the golang built-in crypto library (such as RevocationList.CheckSignatureFrom())?

Primarily, yes. As Patrick mentioned, there will be an additional need for the https://pkg.go.dev/golang.org/x/crypto (which we already use elsewhere) in order to create the OCSP requests (and the mock responses for testing). No other libraries should be necessary based on how I've planned to implement it.

Do we need the ocspTimeoutThreshold field in type revocation struct? Because a http.Client struct has its built in Timeout field (https://pkg.go.dev/net/http#Client), can we use that directly?

The reason I included this is to be forward thinking. The specification states that there should be a different timeout for OCSP and CRL. Once we incorporate CRL revocation, we will need an additional timeout option. Thus, I figured it is best to decouple the OCSP timeout from the client initially in order to minimize the changes that will be necessary to add CRL revocation in the future.

Was thinking more about it and from end user perspective it wouldn't matter if its OSCP or CRL or any other revocation mechanism, they would want revocation to complete in x seconds. Also, we can add ocspTimeoutThreshold in future if some user needs it.

No other libraries should be necessary based on how I've planned to implement it.

That’s great!

Primarily, yes. As Patrick mentioned, there will be an additional need for the https://pkg.go.dev/golang.org/x/crypto (which we already use elsewhere) in order to create the OCSP requests (and the mock responses for testing). No other libraries should be necessary based on how I've planned to implement it.

Awesome, all my questions so far have been answered. This design looks good to me. I guess I'll have further implementation questions once the PR is created. Thanks.


Defaults generator uses invalid tokens

As identified in https://github.com/flutter/flutter/pull/128244, some of the templates use non-existent tokens. These usages should be replaced with valid tokens or removed.

The improvement is provided here: https://github.com/flutter/flutter/pull/140872, so I'm closing this issue:)


Issues about sample_weight

I am using XGBoost to train a data set with sample weights. If I multiply sample weights by a constant (for example, multiply all sample weights by 10, 100, 1000 and so on), I get totally different results with exact same parameters and random_state, I think that while multiplying/dividing sample weights with a constant, results should not change. Is there any mistake? How can I get the same results?

The resulting model would be different. Scaling has different effects on different algorithms that use the weight, along with floating point error, the model is very likely to differ with different scales of weight. Please standardize the value.


Avoid battery going flat without warning

I have occasionally found that when I'm running Crouton I have flattened my battery without warning (running LXDE Trusty). This is fairly serious when I'm working on un-backed-up files, although most of my editors have a fairly forgiving resume.
I'm sure ChromeOS is silently notifying me in the background of battery events, but I need something that has access to the Crouton VT if I'm going to rely on warnings.
Preferably I would like to know if there's a mainstream way to trigger a warning, and then a follow-up auto-suspend on a specific battery percentage. I note that in https://github.com/dnschneid/crouton/issues/71 @dnschneid warns not to enable autosuspend in xfce4-power-manager, so I guess using regular utilities isn't an option.
Are there any options which are known to work apart from rolling your own logic?

@cefn,
I think there would be the theoretical way like this:

Create custom udev rule to watch the battery state and to hook script actions
Create some shell script to warn battery capacities by ringing bell and/or backlight flashing, and to run suspend hook after warning
Insert that rule to /run/udev/rules.d from chroot
Insert those scripts to somewhere

Were those enough? I suppose the owner of udev (and dbus as well) is ChromeOS, so we will have to  make those scripts to run properly from ChromeOS... If so, we also need to set the "absolute path" to script and its contents carefully.
For example, the udev rule is something like this:
# Warn when capacity drops to 7% (and keep warning to 5%)
SUBSYSTEM=="power_supply", \
ATTR{status}=="Discharging", \
ATTR{capacity}=="[5-7]", \
RUN+="WARN_SCRIPT"

# Then drops to 5% or lower, run suspend
SUBSYSTEM=="power_supply", \
ATTR{status}=="Discharging", \
ATTR{capacity}=="[0-5]", \
RUN+="SUSPEND_SCRIPT"

Backlight flashing as warning would be a bit easier than ringing bells via aplay, as long as we want to do sound actions, we have to search some sound files within both ChromeOS and chroot, but backlight control could be done by inserting brightness values to sysfs parameters only without any other resources.
Regards.

Stuff like xfce4-power-manager should work fine inside the chroot.  You just have to go into its settings and make sure it doesn't auto-suspend on idle (auto-suspend on critical power is fine if you want it).


chrome asks to translate the page

when issue the pwmetrics command, google chrome starts up and the UI blocks because chrome asks whether it should "translate this page".
no matter whether I allow/deny this dialog chrome closes after 5 seconds and the console output appears. IMO DX wise it would be less confusing when chrome would not ask questions (or at best would start invisible). couldn't pwmetrics use headless chrome?
Config / CLI options
pwmetrics http://example.com/
Launching Chrome
Audit error: trace not at least 5 seconds longer than FMP Audit key: first-interactive
Audit error: Main thread activity continued through the end of the trace recording. Consistently Interactive requires a minimum of 5 seconds of both main thread idle and network idle. Audit key: consistently-interactive

                                         |
Time to Consistently Interactive (vBeta) | -408,653,676
                                         |
               First Interactive (vBeta) | -408,653,676
                                         |
                  Perceptual Speed Index |                                                     762
                                         |
                  First Meaningful Paint |                                                   739
                                         |
                  First Contentful Paint |                                                   739
                                         --------------------------------------------------------------------
                                          0                 Time (ms) since navigation start                  1000
  ✓ Success: Run 1 of 1 finished successfully.

Environment

pwmetrics version: 3.1.1
Chrome version: 62 nightly
OS version: win10x64

Screenshot

A little surprised by this as I believe --disable-translate is set on the launched chrome instance.. You can verify this by opening about:version in a new tab in that chrome window and checking the flags used.

fwiw  chrome-launcher default flags: https://github.com/GoogleChrome/chrome-launcher/blob/master/flags.ts

Looking into a similar issue for WebPageTest, it looks like the --disable-translate command-line option was removed at some point.

@pmeenan which Lighthouse version do you use?

I'm seeing it independent of Lighthouse (in WebPageTest which uses the same command-line option).
The disable-translate flag was removed ~6 months ago apparently.
It can be disabled with a machine policy (easy on Linux, royal pain everywhere else) or by writing a Preferences file to the profile with the translate preference disabled.  WebPageTest is using both the policy file and pref as of a couple of minutes ago but there's not a good solution for Android yet that I have found.

The disable-translate flag was removed ~6 months ago apparently.

cc @paulirish

It looks like it's not a problem on most platforms because the --disable-infobars command-line option (or one of the others I set) disables the new UI so it's only platforms where the old message box is displayed (Linux in my testing).  Writing a pref to the profile directory before launching or using the policy file both successfully disable it.
For WebPageTest here is the pref file that I write to {profile}/Default/Preferences before launching Chrome.

I experienced the initially reported problem on windows10x64

@pmeenan thank you for these clarifications.
@staabm do you still have this problem, because on macOS it looks fine.

I can still reproduce the issue with pwmetrics 3.1.2 and chrome 64.0.3264.0


Develop

 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.:x: nimai-agarwal sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Update Clickminded link

the link to ClickMinded […] is out of date.

https://twitter.com/TommyGriffith/status/1003221068906053632

👍 URL is: https://www.clickminded.com

Hey @marcobiedermann - is there anything I can do to help get this live?

@trg2 Just fixed it!


Prepare for vgo

This is just random notes to myself:

go.mod is needed not only at ebiten package but also all the example main packages.
To test a new major version on non-master branch, it looks like at least tagging is required. => branch-lookup would solve this: https://github.com/golang/go/issues/24045
vgo run with specifying Go files doesn't recognize the main packages version-ed path. In other words, we can't have the below go.mod for vgo run?

module "github.com/hajimehoshi/ebiten/v2/examples/blocks"

=> (v)go run with package name would be available https://github.com/golang/go/issues/22726

vgo build accepts both modules paths (version-ed and not version-ed) for main packages
Is it possible to prevent from mixing old and new versions?

As Go 1.10.3 already has minimal support for semantic versioning import paths, I think I can release 2.0 sooner than I expected (e.g. next to 1.8)?

go.mod already exists and let's keep updating it.


[Enquiry] Iterate over files with filetype in current directory

Dear John,
Thank you for the excellent lib. I am trying to learn how to use it. How can I iterate over all files with .md extension in the current folder?
I am stuck with:
for file in try Folder(path: Folder.current).files {
...
}

What is the proper use?
Thank you.

Hi @lf-araujo 👋
Here's how to do it:
for file in Folder.current.files {
    guard file.extension == "md" else {
        continue
    }

    // Your code here
}


Add Expectation.shouldContain(String)

Original author<EMAIL_ADDRESS>(July 28, 2011 23:25:21)
so as not to write things like
a(myString.contains("hello")).shouldBeTrue();
better syntax:
a(myString).shouldContain("hello");
Original issue: http://code.google.com/p/activejdbc/issues/detail?id=100

This was done, I just made a small correction. Issue can be closed.

cool!


Could you provide an example on how to properly use template.parent

Hi
Bit of a new guy on the block but can't find a good example on how to make template.parent work
Do I put in in a helper function, on rendered and how is it returned
Sorry for this basic question as I can't find a good sample to use so far
I want it to access this helper on the parent template
Template.course.helpers({'builder' : function(itemType) {
    var courseBuilder = 'itemType';
    Session.set('builder', courseBuilder);
    return Session.get('builder') === itemType}
});```

@rufusthecat template.parent actually gets the parent template instance, and is on a template instance. So assuming you have template variable which is the instance of a template within an instance of "course" (e.g., this within onRendered or using Template.instance()), then the parent helpers are on template.parent().template.__helpers property. But you might just want to inherit them on the child template with Template.child.inheritsHelpersFrom('course')

Thanks for your feedback


Closes #741: Can't delete disabled wireless networks

When a wireless network is disabled it can't be removed. From
wifi_overview.htm the delete call is generated as wlan0, wlan1 or
whatever. This wlan is not working because it is disabled, then LuCI
deletes the virtual radio which really is named as wlan0.

Merged, thank you!


iced 0.6.0 requires iced_lazy 0.3.0

Is there an existing issue for this?

[X] I have searched the existing issues.

Is this issue related to iced?

[X] My hardware is compatible and my graphics drivers are up-to-date.

What happened?
iced 0.6.0 requires iced_lazy 0.3.0, but but officially available only 0.2.0
What is the expected behavior?
For pane_grid example replace cargo.toml
[dependencies]
iced = { path = "../..", features = ["debug"] }
iced_native = { path = "../../native" }
iced_lazy = { path = "../../lazy" }
iced = { version = "0.6.0",  features = ["debug"] }
iced_native = "0.7.0"
iced_lazy = "0.2.0"
And get two errors:
the trait bound iced_native::Element<'_, _, _>: From<Responsive<'_, _, _>> is not satisfied
the following other types implement trait From<T>:
<iced_native::Element<'a, Message, Renderer> as From<&'a str>>
...
mismatched types
expected struct iced_native::element::Element<'_, _, _>
found struct iced_native::Element<'_, Message, iced_graphics::renderer::Renderer<iced_wgpu::backend::Backend, Theme>>
perhaps two different versions of crate iced_native are being used?
Version
master
Operative System
Windows
Do you have any log output?
No response

Forgot to push that one! It should be released now.


Ensure that metaclasses are in the class table when instantiated.

Ensure that metaclasses are in the class table when instantiated. Bad
things happen to their instances otherwise.
This solution mirrors what original Spur does (the invocation of ensureBehaviorHash: in Spur*MemoryManager>>instantiateClass:indexableSize:). We can remove the class hash check in removeUnmarkedOldObjects().

I hope 3ac9a12d5100407d944ea3fec1b4f508b2601db9 fixes this without touching instantiateClass, so no perf impact at runtime.


ENH: Replace MCFLIRT with 3dVolReg

Ports over https://github.com/nipreps/fmriprep/pull/1354 to replace MCFLIRT call with 3dVolReg.
The makeshift interface for converting between transform formats seems ideal for nitransforms.
Missing

[ ] Framewise displacement calculation

Let's not worry about the FD right this minute.


Cannot install CocoaPods 1.12 in CI, failed installing dependency json 2.6.3 with native extensions

Dependabot tried to bump the cocoapods gem from 1.11.3 to 1.12.0 in https://github.com/flutter/flutter/pull/122051, but gem installation json dependency fails:
Installing json 2.6.3 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

current directory:
/Volumes/Work/s/w/ir/x/w/gems/ruby/3.1.0/gems/json-2.6.3/ext/json/ext/parser
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/bin/ruby
-I
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0
extconf.rb
checking for rb_enc_raise() in ruby.h... *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
	--with-opt-dir
	--with-opt-include
	--without-opt-include=${opt-dir}/include
	--with-opt-lib
	--without-opt-lib=${opt-dir}/lib
	--with-make-prog
	--without-make-prog
	--srcdir=.
	--curdir
--ruby=/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/bin/$(RUBY_BASE_NAME)
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:490:in
`try_do': The compiler failed to generate an executable file. (RuntimeError)
You have to install development tools first.
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:583:in
`try_link0'
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:601:in
`try_link'
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:812:in
`try_func'
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:1116:in
`block in have_func'
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:989:in
`block in checking_for'
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:354:in
`block (2 levels) in postpone'
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:324:in
`open'
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:354:in
`block in postpone'
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:324:in
`open'
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:350:in
`postpone'
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:988:in
`checking_for'
from
/Volumes/Work/s/w/ir/cache/ruby/.cipd/pkgs/0/TyvPskvefNRkTDmiDcwRHrdL_a2FQE_4wBojOqhxdtYC/lib/ruby/3.1.0/mkmf.rb:1115:in
`have_func'
	from extconf.rb:4:in `<main>'

To see why this extension failed to compile, please check the mkmf.log which can
be found here:

/Volumes/Work/s/w/ir/x/w/gems/ruby/3.1.0/extensions/x86_64-darwin-21/3.1.0-static/json-2.6.3/mkmf.log

extconf failed, exit code 1

Gem files will remain installed in
/Volumes/Work/s/w/ir/x/w/gems/ruby/3.1.0/gems/json-2.6.3 for inspection.
Results logged to
/Volumes/Work/s/w/ir/x/w/gems/ruby/3.1.0/extensions/x86_64-darwin-21/3.1.0-static/json-2.6.3/gem_make.out

An error occurred while installing json (2.6.3), and Bundler cannot continue.
Make sure that `gem install json -v '2.6.3' --source 'https://rubygems.org//'`
succeeds before bundling.

In Gemfile:
  cocoapods was resolved to 1.12.0, which depends on
    cocoapods-core was resolved to 1.12.0, which depends on
      algoliasearch was resolved to 1.27.5, which depends on
        json

https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8787336528606460385/+/u/Install_gems/install_gems/stdout

We'll need to find a way to provide gem dependencies in a hermetic way. Fixing this will probably require changes to the ruby CIPD package.
I'd recommend to skip the update for now.

Removing from ticket queue as this is not blocking the tree.

This is blocking upgrade to Xcode 14.3 (or we need to turn off some tests) https://github.com/flutter/flutter/issues/125812

Link to docs: go/flutter-ruby

This is blocking upgrade to CocoaPods 1.13.0, which is something we'll want to fix for Xcode 15.
Issue: https://github.com/flutter/flutter/issues/133584
Related: https://github.com/flutter/flutter/issues/133584
Post-upgrade doctor check: https://github.com/flutter/flutter/pull/135447

The current way to build ruby cipd package is super complicated. There is some discussion about using ruby from xcode, but seems latest xcode doesn't come with a ruby. Another option is use the system default ruby from the latest Mac OS.
/cc @godofredoc @vashworth @christopherfujino per https://chat.google.com/room/AAAAQFWU2Go/OJo_G09vo5o

One thing to keep in mind when working on this: We can't copy ruby headers into Xcode as we have been doing with macOS 13.

Umbrella bug for updating the ruby self contained package: https://github.com/flutter/flutter/issues/136377

Cocoapods is now installed as part of the ruby bundle.


[SMALLFIX] Add mount points to master info REST endpoint.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12483/
Test PASSed.

Merged build finished. Test PASSed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12486/Failed Tests: 1org.alluxio:alluxio-tests: 1alluxio.master.AlluxioMasterRestApiTest.getMountPoints
Test FAILed.

please fix the failing test

I don't think we should be using the actual UFS data

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12487/Failed Tests: 1org.alluxio:alluxio-tests: 1alluxio.master.AlluxioMasterRestApiTest.getMountPoints
Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12488/Failed Tests: 1org.alluxio:alluxio-tests: 1alluxio.master.AlluxioMasterRestApiTest.getMountPoints
Test FAILed.

Merged build finished. Test FAILed.

@uronce-cc is this PR ready to review? I see test is still failing

jenkins, test this please

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12508/
Test PASSed.

Merged build finished. Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/12509/
Test PASSed.

@apc999 Tests are fixed.


refactor(core&api)!: hide internal functions & resuse them in api.js & rename tauri module to primitives

ref: https://github.com/tauri-apps/tauri/issues/7756

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Docs
[ ] New Binding issue #___
[ ] Code style update
[x] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change?

[x] Yes, and the changes were approved in issue #___
[ ] No

Checklist

[x] When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
[x] A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
[x] I have added a convincing reason for adding this feature, if necessary

Other information
This PR aims to hide all internal functions and properties from the global window object and to window.__TAURI__.__INTERNALS__ and also changes @tauri-apps/api to use these functions instead of redefining the logic again.
Also renamed tauri module to primitives and removed the undocumented invoke re-export in the root module.

There's a reason we're not adding everything on TAURI: we replace that whole object if withGlobalTauri is set to true: https://github.com/tauri-apps/tauri/blob/c0d03af4704c828698e06e9662dab1087c99c42e/tooling/api/tsup.config.ts#L31
I pushed some changes on your script, but that part of this PR can't be touched (unless we rename TAURI to something else for core scripts).

I guess we need to change the place we store these internals, or change window.__TAURI__ = __TAURI_IIFE__ to window.__TAURI__ = { window.__TAURI__, ...(__TAURI_IIFE__) }

Moved to window.__TAURI_INTERNALS__


Tester UI

Here is a Tester UI Java Swing app . It's not a full fleged Exerciser but you can work in a similar manner with it.

Maybe it is worth a new release 2.1.0 like proposed in this branch

I merged the content and updated the scripts to reference 2.1.0 jar files. If you are ready to release I'll push to Maven Central.

Nice


*: use the cluster domain of underlying k8s

fix https://github.com/coreos/etcd-operator/issues/1021

lgtm. not sure why we need the suffix at the first place.

I still need to fix some TLS stuff.
Please hold on.

Fixed.
Ready to go!

@hongchaodeng will this break compatibility?
create a cluster in 0.5.1
upgrade to 0.5.2
add member to the cluster created by 0.5.1
will the new member work correctly?

will this break compatibility?

For normal cluster, it should just work.
For TLS cluster, it will need rotating certs to allow both DNS names.

I have tried with upgrade. It seems that operator can't manage etcd cluster after upgrade because etcd serves old cert even new secrets containing certs allowing both domains.
For example, I have v0.5.0 operator create an etcd cluster. Then the cluster serves only *.example.default.svc.cluster.local domain. After upgrade, operator would try to contact example-0000.example.default.svc and fail.
One workaround is try to manually "upgrade" etcd pod in order to restart it. For example, upgrade from "3.1.8" to "3.1.9", then etcd pod will restart safely and load the new certs. Then etcd operator can manage them

@xiang90
Pod's A records seems a better option. We might want to change to use that instead of headless service. I also try out hostNetwork and it works too.
We might continue in this PR to change it to use Pod's A records instead to solve it all at once.

All addressed.
Ready to go now.

lgtm


[XamarinWorkbooks-Windows]: Accessibility:MAS4.2.1:Inspect: PositionInSet and SizeofSet property is not defined for 'Workbook' and 'Inspect' tab items

Steps to Reproduce

Open "Xamarin Workbook"
Products window is opened.
Navigate to the "wpf "icon and select "create workbook".
Navigate to 'Workbook/view inspect' tab item and Observe Inspect properties

Expected Behavior
PositionInSet and SizeofSet should be properly defined for tab items
Actual Behavior
PositionInSet and SizeofSet property is not defined for 'Workbook' and 'Inspect' tab items
Narrator Behavior: Narrator is announcing as 'selected, workbook tab item'
NVDA behavior:NVDA is announcing as 'Workbook tab selected'
User Impact:
User who rely on screenreader will not not be able to know position and Size of tab items
Screen-Shots:

Environment:
Windows :Windows 10 Pro Version 1803 (OS Build : 17672.1000)
Xamarin Version : 1.4 (master/b3f92f9)
NVDA Version: 2018.1

Log File

Please add the following labels to the bug:
A11yMAS
Accessibility
Xamarin-Workbooks-Windows
Wipro
MAS4.2.1


Appropriate license for external C files

Reported by beutlich on 24 Jun 2014 20:09 UTC
This one came up when evaluating the Noise lib for MSL potential integration. See also https://github.com/DLR-SR/Noise/issues/9 and https://github.com/modelica/Modelica_DeviceDrivers/issues/35.
Is it right to have the external C source and header files licensed under Modelica License 2? Usually only the Modelica files of a package use Modelica License 2 whereas C source and header files use some more appropriate license like BSD3.
Current state: In MSL there are ModelicaInternal.c and ModelicaStrings.c licensed under Modelica License 2 whereas ModelicaStandardTables.* are ModelicaMatIO.* are licensed under BSD3. win32_dirent.* is public domain.
In the MSL readme.txt it treads
All files in this directory (Modelica) and in all subdirectories,
especially in Modelica/Resources/* are licensed
by the Modelica Association under the Modelica License 2

thus with emphasis on the C sources. What is the reason that Modelica License 2 is used here? Or is it just a mistake in the DLR library template?

Migrated-From: https://trac.modelica.org/Modelica/ticket/1525

Comment by sjoelund.se on 25 Jun 2014 05:03 UTC
Replying to [ticket:1525 beutlich]:

In the MSL readme.txt it treads
All files in this directory (Modelica) and in all subdirectories,
especially in Modelica/Resources/\* are licensed
by the Modelica Association under the Modelica License 2

(It also lists the tables C-Sources as exceptions. Same thing in the package.mo, which contains the license).

Comment by beutlich on 25 Jun 2014 07:26 UTC
Replying to [comment:1 sjoelund.se]:

Replying to [ticket:1525 beutlich]:

In the MSL readme.txt it treads
{{{
All files in this directory (Modelica) and in all subdirectories,
especially in Modelica/Resources/* are licensed
by the Modelica Association under the Modelica License 2
}}}

(It also lists the tables C-Sources as exceptions. Same thing in the package.mo, which contains the license).

Yes I know. Forgot to mention it here since focus is on ModelicaInternal.c and ModelicaStrings.c.

Comment by beutlich on 5 Aug 2014 10:29 UTC
Any comments from map-lib deciders?

Modified by beutlich on 19 Aug 2014 08:25 UTC

Comment by dietmarw on 19 Dec 2014 07:01 UTC
Ticket retargeted after milestone closed

Modified by beutlich on 20 Feb 2015 14:42 UTC

Comment by hansolsson on 23 Feb 2015 17:34 UTC
Modelica design meeting:
No conclusion.
The problem is you want to take C-code from MSL and use it in an unrelated project.
Using BSD (3?) seems like a solution.
Also problem with maintaining unmaintained Modelica libraries - since we want to upgrade (not a bug fix) and change version but not the name.

Comment by dietmarw on 15 Apr 2015 14:33 UTC
Ticket retargeted after milestone closed

Comment by beutlich on 5 May 2015 13:24 UTC
Replying to [comment:7 hansolsson]:

The problem is you want to take C-code from MSL and use it in an unrelated project.
Using BSD (3?) seems like a solution.

Yes, changing the license of the external C-code of Modelica libraries like Modelica_DeviceDrivers or Noise to BSD3 looks correct to me.

Also problem with maintaining unmaintained Modelica libraries - since we want to upgrade (not a bug fix) and change version but not the name.

The same naming issues already exists, if the (Git) repository of a Modelica library under Modelica License 2 is forked.

Comment by dietmarw on 26 Jun 2015 14:54 UTC
Ticket retargeted after milestone closed

Modified by beutlich on 6 Aug 2015 07:27 UTC

Comment by ahaumer on 24 Sep 2015 10:28 UTC
Discussion during 87th meeting in Paris:
Change license from Modelica License 2 to BSD 3-clause
Poll:	In favour:	12
Against:	1
Abstain:	10
Martin formulates a proposal and explains why,
Toni starts electronic voting within MAP-Lib

Comment by beutlich on 24 Sep 2015 21:53 UTC
There currently is an issue with the license of the FMI 2.0 files, see #351. As pointed out at the 87. MDM the license of the FMI files and the external C files of the MSL should be available under the same license. Thus it might be also be necessary to change the license to BSD 2-Clause here for files ModelicaStandardTables.[ch], ModelicaStrings.c and ModelicaInternal.c.
Edit: ModelicaRandom.c (of Modelica Noise) currently is licensed under BSD 2-Clause.

Comment by beutlich on 29 Sep 2015 20:33 UTC
Replying to [comment:12 ahaumer]:

Martin formulates a proposal and explains why,
Toni starts electronic voting within MAP-Lib

Comment by beutlich on 6 Oct 2015 08:54 UTC
Martin, when do you plan to formulate the proposal? As stated in comment:13 the used licenses are currently pretty messy. Actually I'd like to see BSD 2-Clause but at the 87. MDM we voted on BSD 3-Clause.

Comment by sjoelund.se on 7 Oct 2015 07:48 UTC
2-clause or 3-clause makes only a small difference. But considering we want Modelica to be spread, it would make sense to not gag people from saying the MA developed ModelicaStandardTables, etc.
The added clause:

Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

Comment by beutlich on 7 Oct 2015 07:58 UTC
I think there is pretty much agreement here to not have the third BSD clause.

FMI files are BSD 2-Clause (they should be)
ModelicaRandom.c is BSD 2-Clause
ModelicaMatIO.[ch] is BSD 2-Clause

Comment by hansolsson on 7 Oct 2015 10:39 UTC
Replying to [comment:16 sjoelund.se]:

2-clause or 3-clause makes only a small difference. But considering we want Modelica to be spread, it would make sense to not gag people from saying the MA developed ModelicaStandardTables, etc.

I don't see the point is about 'MA developed ModelicaStandardTables'; but about what you say about your own product using ModelicaStandardTables - and its contributors.
That is I thought the goal of 3rd clause was more that people are not allowed to say
'MyModelicaTool - using the latest ModelicaStandardTables developed by ITI'
'MyModelicaTool - the official Modelica Association tool',
I can see that these can be problematic, and I am not sure you are allowed do that even without the 3rd clause (unless you have permission). [Not saying that they make sense from a marketing perspective.] On the other hand a tool could just mention that 'MA developed ModelicaStandardTables' in some non-endorsing way; which should be ok.
The endorsement part and name of contributors seems the most problematic; note that some Creative Commons Licenses also include non-endorsement texts, as well as clause 7 of Modelica License 2. The Creative Commons is interesting since CC-BY-3.0 has a non-endorsement clause, but CC-BY-4.0 states that the license does not grant you the endorsement right.

The added clause:

Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

Comment by dietmarw on 8 Oct 2015 10:10 UTC
Although guilty myself of voting for the BSD-3 clause back in Velizy , now, after I had actually some time to reflect the implications I think we should be pragmatic and ask ourself if something like this is going to happen:
Replying to [comment:18 hansolsson]:

That is I thought the goal of 3rd clause was more that people are not allowed to say
'MyModelicaTool - using the latest ModelicaStandardTables developed by ITI'
'MyModelicaTool - the official Modelica Association tool',

will we as MA actually put energy and resources into following up this kind of miss-endorsement. And I think the answer is no. So we might just as well drop that third clause and be honest with ourselves and go for the BSD-2 clause licence.

Comment by otter on 8 Oct 2015 10:20 UTC
I am also strongly for the BSD 2 clause license. Reasons:

The third clause of the BSD 3 clause license is difficult to understand and also the consequences are not obvious.

I have seen presentations about "open source licenses" where the advice was given, to not mention at all the authors of the open source product, in order to not violate the third clause (although in my opinion this is wrong and violates the other clause). This would be completely against the intention of the BSD clause: "do with it what you want, but give credits to me and do not make me responsible if there are bugs".

Comment by beutlich on 8 Oct 2015 10:36 UTC
Fine that there is some agreement on using the BSD 2-Clause license. How to continue?

@otter: Are you going to formulate some proposal and we accept it without voting?
@otter: Are you going to formulate some proposal and set up some voting?
Should we ignore the Velizy voting and change the licensing according to our all new understanding?

Comment by hansolsson on 8 Oct 2015 10:38 UTC
Replying to [comment:20 otter]:

I am also strongly for the BSD 2 clause license. Reasons:

The third clause of the BSD 3 clause license is difficult to understand and also the consequences are not obvious.

I agree that the consequences are not obvious - but to me this applies also to BSD 2 clause, and I would hope that some lawyer could resolve this.
To me it would be logical that BSD 2-clause doesn't grant me the right to use contributors etc to endorse and promote a product.
So, why did someone think it necessary to include the 3rd clause? One could think it was just a mistake a long time ago, but Creative Commons also use various non-endorsements clauses.
The Creative Commons in their FAQ mention that they make the non-endorsement 'explicit'; sort of indicating that it is implicit in other cases and it just seems like a way to cover themselves.

Comment by otter on 8 Oct 2015 11:12 UTC
Replying to [comment:22 hansolsson]:

Replying to [comment:20 otter]:

I am also strongly for the BSD 2 clause license. Reasons:

The third clause of the BSD 3 clause license is difficult to understand and also the consequences are not obvious.

I agree that the consequences are not obvious - but to me this applies also to BSD 2 clause, and I would hope that some lawyer could resolve this.
To me it would be logical that BSD 2-clause doesn't grant me the right to use contributors etc to endorse and promote a product.
So, why did someone think it necessary to include the 3rd clause? One could think it was just a mistake a long time ago, but Creative Commons also use various non-endorsements clauses.
The Creative Commons in their FAQ mention that they make the non-endorsement 'explicit'; sort of indicating that it is implicit in other cases and it just seems like a way to cover themselves.

For Modelica Association it does not matter, if someone wants to say, "I am using this code from MA (and since it is from MA it is high quality)", or someone just ships the conditions (say, within the MSL). Therefore, whatever interpretation the user has, it does not matter for us. There are so many other high priority issues, that we should not spend time on a really tiny issue where a good solution is available and we just have to copy this into the MSL.
We probably still should have a vote: "BSD 2 clause" yes/no.
Toni, can you organize this. Proposal for text:
It is proposed to change the license of the C-source code shipped with MSL that has been provided by MA members. The current "Modelica License 2" shall be replaced by the BSD 2-clause license (https://opensource.org/licenses/BSD-2-Clause).
Do you agree: yes/no.

Modified by beutlich on 8 Oct 2015 11:24 UTC

Comment by hansolsson on 9 Oct 2015 09:11 UTC
To me it seems best to first determine the facts, and then take the decision.
After some searching it seems the non-endorsement clause is basically meaningless, and there is no practical difference between 3-clause and 2-clause BSD, see e.g.
http://choosealicense.com/licenses/
which seems very reliable and indicates that the non-endorsement is implicit anyway.
(You have to click around a bit to find 3-clause BSD and that text.)
If someone disagrees with this (and prefer 3-clause BSD) they should explain why.
Replying to [comment:19 dietmarw]:

Although guilty myself of voting for the BSD-3 clause back in Velizy , now, after I had actually some time to reflect the implications I think we should be pragmatic and ask ourself if something like this is going to happen:
Replying to [comment:18 hansolsson]:

That is I thought the goal of 3rd clause was more that people are not allowed to say
'MyModelicaTool - using the latest ModelicaStandardTables developed by ITI'
'MyModelicaTool - the official Modelica Association tool',

will we as MA actually put energy and resources into following up this kind of miss-endorsement. And I think the answer is no. So we might just as well drop that third clause and be honest with ourselves and go for the BSD-2 clause licence.

Both MA and ITI can in the scenario above still act if their trademarks/logos are used inappropriately (which would be the case above). And there are also other rules against false advertising.
If people just claim that MSL and Modelica are developed by Modelica Association they can use Modelica-logo etc according to our updated rules (independent of this license).

Comment by beutlich on 27 Oct 2015 13:00 UTC

Toni, can you organize this. Proposal for text:
It is proposed to change the license of the C-source code shipped with MSL that has been provided by MA members. The current "Modelica License 2" shall be replaced by the BSD 2-clause license (https://opensource.org/licenses/BSD-2-Clause).
Do you agree: yes/no.

Toni: Bump. There are only about two months left for MSL 3.2.2 release (according to the minutes from the 87. MDM in Velizy) and I do not want to vote on New Year's Eve. So let's please finalize this annoying license ticket if there is even agreement among the panel list. Thanks!

Comment by ahaumer on 19 Nov 2015 10:27 UTC
The electronic voting gave the following result:
9 votes, all in favor.
So you can proceed with the https://opensource.org/licenses/BSD-2-Clause.
What do we have to do to close the ticket?

Comment by beutlich on 19 Nov 2015 14:42 UTC
Replying to [comment:27 ahaumer]:

The electronic voting gave the following result:
9 votes, all in favor.

Thanks.

So you can proceed with the https://opensource.org/licenses/BSD-2-Clause.
What do we have to do to close the ticket?

Change the license comments in the appropriate files and the readme's. Will do it.

Comment by beutlich on 25 Nov 2015 10:48 UTC
Resolved by ae5252055b23c016787957582c9089ab69805c82.

Changelog modified by beutlich on 25 Nov 2015 10:48 UTC
Changed license of ModelicaExternalC C sources to BSD 2-Clause License (aka Simplified BSD License)


Blank Pages w/ 500 error on initial load

Sometimes, when you navigate to a fresh uncached page, you receive a blank object, {}, and a 500 error  is logged. This happens mostly on the proposal view page and proposal editing (even if you don't have redirection enabled).
Could be:

SSR
Code spliiting
Poor try/catches or error piping.

Ideal outcome is more specific errors.

Removing the <script async /> parts of renderPage have stopped issues where webpack chunks fail to load in order (I think async content loading doesn't work well with my implementation of code splitting), however, there's a second source of this problem. It usually presents itself when I initially load proposals.


Spelling Error in AccountPolicy resource

I know it's a minor change with a major impact to anyone using version <IP_ADDRESS>, but can the spelling for 'Enfore_user_logon_restrictions' be corrected to 'Enforce_user_login_restrictions'?

@aydeisen good catch. The dev branch has been updated.

Thank you.  One more under the Security Option resource:
Interactive_logon_Require_Domain_Controller_authenticatio_to_unlock_workstation should be Interactive_logon_Require_Domain_Controller_authentication_to_unlock_workstation
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10
From: Jason<EMAIL_ADDRESS>Sent: Monday, October 9, 2017 14:26
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [PowerShell/SecurityPolicyDsc] Spelling Error in AccountPolicy resource (#60)
@aydeisenhttps://github.com/aydeisen good catch. The dev branch has been updated.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/PowerShell/SecurityPolicyDsc/issues/60#issuecomment-335246863, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANZGFajT4TuPpoAS8GVdrv3OMOdw9xIcks5sqmVIgaJpZM4Pyyq8.


[HTTPCLIENT-1810] URIBuilder.toString() always adds '/' to path, even with query parameters

When the path is null or '', URIBuilder.normalizePath() should return '' rather than '/'.

Committed to SVN trunk. Please review and close.

There still appear to be an issue with normalizePath starting with 4.5.3 which adds a leading '/'. If you do normalizePath("https://www.google.com/"); the result is /https://www.google.com/


Get test_memoryview passing

... Kind of.
I have a couple pieces of the implementation that I think need revision, namely:

When I added weakref support to memoryview, for some reason it wasn't releasing in time for the net4.5 target when run through make.ps1 tests. If I ran test_memoryview in any other circumstance the weakref seemed to release appropriately. I left it out for now, but it might be a good idea to investigate, given that we've seen something similar in #544.
The change to suboffsets (empty tuple instead of None) should probably be handled on the other side of the IBufferProtocol instead of in memoryview, right?

If adding gc.collect() works to fix the weakref, would you also be okay with adding that into the test in case the implementation is ironpython or do you think it's better to leave the test disabled?

Yes, you can just add something like gc.collect() # required by IronPython, probably no need to conditionally exclude. I did something like that in test_deque (although I think it still fails once in a while).

It still consistently failed when run from make.ps1. The test currrently calls support.gc_collect(). Maybe it has to do with Release vs Debug version?

It looks like changing the IsolationLevel seems to make test_weakref work. I'm fine with either skipping it (as long as an issue is filed -- even if it just says the test if failing for unknown reasons -- and you add a link to it in a comment in the source) or changing the IsolationLevel in AllCPythonCasesManifest.ini:
IsolationLevel=PROCESS # https://github.com/IronLanguages/ironpython3/issues/489

Just a quick update since I left this hanging so long. Since test_file seems to be a case of a weakref not releasing as well, I think they should be in the same status so I think I'll mark set IsolationLevel=Process as above.
The remaining hangup that I'm working on is that my conversion to an int (line 421) doesn't work above for floats and the other types, and I'm trying to come up with a clean way of giving the correct responsibility of error handing to MemoryView and TypecodeOps.

Sounds like you might need a switch based on format to do the proper conversions?

I guess I think it should be done in MemoryView. This is a little closer.

Seems like a serious case of me not cleaning up the things I started but didn't like. Sorry for making you review all of this!

I'm fine with reviewing, helps me get more familiar with the codebase. :)

Looking at the CI, it looks like the failures on Mono are weakref related? I would be fine with just skipping testing on Mono (by adding RunCondition=NOT $(IS_MONO) with a comment to AllCPythonCasesManifest.ini).

Other than the fast track, I don't think anything comes to mind. The last piece is indexing at a tuple, but I think that should be another pull request, and I don't believe it's blocking anything for IronPython.
Thanks for the patience and the helpful reviews with this one!
I believe that the remaining things to do after this is merged are:

Add a comment to #544
Add a comment to #489

Thanks for the PR!


Malformed XML: No element found at /mingw64/

Hi,
I am trying to migrate a big SVN repo (15k revisions) and after 12k revisions it fails with this error:
Malformed network data:  The XML response contains invalid XML: Malformed XML: no element found at
/mingw64/share/perl5/site_perl/Git/SVN/Ra.pm line 312.
It seems to be a Perl issue.
I have tried to execute the same command on Windows, MAC OS and Linux and I got the same message.
Do you have any clues about solving this issue?
Thanks,
Andrei

Sorry. That error would be originating from git-svn. svn2git is basically a wrapper around git-svn that makes it easier to use. But, ultimately, we're subject to all of their bugs. You'd have to ask on the git mailing list or file an issue with them I'm afraid.


Typos within original text.

How should we approach typos in the original text? Should we go in and fix these or leave them? I did not find many of these, but I have linked an example from page 221, Chapter 13 (There is a missing period at the end of the quote).

Does anyone have any thoughts on this?  I think perhaps we should just leave them in.

I would encourage fixes of obvious typos of this sort.

Fix issues when they pop-up, but save these minor edits for the end/future work.


Add custom-made tooltip for information-icon in menu (hover state)

title attribute is too slow to pop-up

Not relevant anymore because we scrapped the information icon concept


Add 3 new paths for list cluster kubeconfig

This PR adds 3 new paths for list cluster kubeconfig, they're 1-to-1 mapping with current listCredential handler:

listClusterAdminKubeConfig(new) - listClusterAdminCredential(old)
listClusterUserKubeConfig(new) - listClusterUserCredential(old)
listClusterMonitoringUserKubeConfig(new) - listClusterMonitoringUserCredential(old)

The new handler will only return static token in kubeconfig due to certificate's permission is not correct.
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[X] new API version - added 3 paths in new API version 2021-09-01
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month. October.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month. October.
If updating an existing version, please select the specific langauge SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[X] I commit to follow the Breaking Change Policy of "no breaking changes"
[X] I have reviewed the documentation for the workflow.
[X] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[X] Check this box if any of the following apply to the PR so that label “WaitForARMFeedback” will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[X] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits.

[X] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

The failed CI is due to the target branch is not main, similar as https://github.com/Azure/azure-rest-api-specs/pull/15976 . Not related to the swagger change.

Abandoned as pre discussion, we decided not to add new handler.


[SPARK-41113][BUILD] Upgrade sbt to 1.8.0

What changes were proposed in this pull request?
This pr aims to upgrade sbt from 1.7.3 to 1.8.0
Why are the changes needed?
This version fix 2 CVE:

Updates to Coursier 2.1.0-RC1 to address https://github.com/advisories/GHSA-wv7w-rj2x-556x
Updates to Ivy 2.3.0-sbt-a8f9eb5bf09d0539ea3658a2c2d4e09755b5133e to address https://github.com/advisories/GHSA-wv7w-rj2x-556x

The full release notes as follows:

https://github.com/sbt/sbt/releases/tag/v1.8.0

Does this PR introduce any user-facing change?
No
How was this patch tested?

Pass GitHub Actions
Run  dev/sbt-checkstyle passed

test first

cc @HyukjinKwon

cc @linhongliu-db too

@LinhongLiu Please help double check. Thanks ~
I don't know what you need. I just checked dev/sbt-checkstyle manually

That will be enough, @LuciferYang .
Thank you, @LuciferYang and @HyukjinKwon . Merged to master.

Thanks @dongjoon-hyun @HyukjinKwon