⚠ Bofrost.be has degraded performance

In 91c4607, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1658 ms

Resolved: Bofrost.be performance has improved in 043f09d.


automated_loads disabled some form fields on edit

Maybe I missed something but where is the true / false values for each specific form?
Also I think I like the props idea vs the long lists of params coming into the method... what do you think?


spyder/app/tests/test_mainwindow.py::test_runcell_pdb fails

Issue Report Checklist

[ ] Searched the issues page for similar reports
[ ] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
[ ] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
[ ] Could not reproduce inside jupyter qtconsole (if console-related)
[ ] Tried basic troubleshooting (if a bug/error)

[ ] Restarted Spyder
[ ] Reset preferences with spyder --reset
[ ] Reinstalled the latest version of Anaconda
[ ] Tried the other applicable steps from the Troubleshooting Guide

[ ] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description
spyder/app/tests/test_mainwindow.py::test_runcell_pdb fails
What steps reproduce the problem?

Create a PR against 5.x
Push it

What is the expected output? What do you see instead?
Paste Traceback/Error Below (if applicable)

PASTE TRACEBACK HERE

Versions

Spyder version:
Python version:
Qt version:
PyQt version:
Operating System name/version:

Dependencies

PASTE DEPENDENCIES HERE

I've seen failures related to that test, but I think that's because it's quite flaky, specially on Mac. On Linux and Windows it seems to be working fine.

There is a race condition, and it seems that the update to the ipythonconsole plugin triggers the failure consistently for the mac test. This is an issue with qtconsole.


Refactor start-h2 logic

Description
Moved StartH2Main from being a stand-alone command to being integrated into the StartH2CommandStep.
The old examples/start-h2 scripts are still there, but are now calls to liquibase init start-h2 rather than a separately boostrapped java call to StartH2Main.

Code review and test results:
Things to be aware of

There were two copies of the start-h2 scripts, I deleted the uneeded copy and made sure the remaining copy was correctly copied (preserved unix permissions and dos/unix line endings ) into the final tar.gz file

Would like a double-check that these files still work from official build

The code in StartH2CommandStep is copy-pasted from the old StartH2Main

But I did move some hard-coded settings like ports and username/password to be arguments now that that is easy to do

I found the h2.bindAddress system property, which looks like the one h2 uses to decide the IP/host to connect to. Without that setting, it would guess at the best one and sometimes get it wrong.

In our case, we want it to be localhost for security reasons, but there is a new arg for people who don't want that

There is a corresponding pro PR and also Datical/liquibase-docs#137

Things to worry about

Does the old start-h2 scripts still work on mac/linux and windows? Does liquibase init start-h2 still work?

The "does it start" is the main thing that changed. The logic within is mostly the same.

@nvoxland Are you going to remove the com.datical.liquibase.ext.command.init.StartH2CommandStep from the pro code?

Yes, there is a corresponding PR that removes that

@nvoxland I've noticed that when I CTRL+C in the prompt where H2 is running, it takes a few seconds before the command is interrupted. Is that something that can be fixed, and is it fixed by your changes here?

I added a commit to better handle that pause after "ctrl-c"
I also updated the readme and getting_started pages

This fix adds a new command  liquibase init start-h2 to start an example h2 DB, keeping the bat script (the bat command uses liquibase init start-h2 now too). The only functional test that i could think so are using  liquibase init start-h2  command with this build and then use the bat file on an older build and compare their behavior.
Both ways work the same way so i procided to check bugfixes and the things to be aware of by Nathan:

Retain start-h2 files in the examples directory, but they call liquibase init start-h2 and not StartH2Main. PASS
No documentation references to start-h2, only liquibase init start-h2 PASS
If you run liquibase init start-h2 with no h2 jar file in your liquibase/lib dir, the error message is valid PASS
Browser opens to "localhost" not an IP address FAIL
URLs shown in the console output are "localhost" and not an IP address FAIL
(4 and 5 failed in my environment but after trying on my coworker environement it looks like my case is uncommon, it is a thing to be aware of though)

Test environment
Liquibase Version: [Core: //start-h2-simplify/2477/50379f/2022-05-02 17:04+0000, Pro: start-h2-simplify/1078/c6d556/2022-05-02T16:59:19Z] #2477 built at 2022-05-02 17:04+0000
h2 2
jdk 1.8.0_291


bindBuffer error causing graphics glitches

We're currently working on a WebGL/Web Audio experiment that has up to 5 WebGL contexts running at once. Intermittently - sometimes a few seconds in, sometimes several minutes in - we receive the following error:
WebGL: INVALID_OPERATION: bindBuffer: object not from this context
This causes graphical glitches to occur in one or more of the WebGL renderers. In the attached, you can see a glitched-out parallelogram in the top left of the panel.
Any insight you have into this error is welcomed. Thanks!

Very weird, not sure why this would happen just looking at the code. Anyway you could share a running example? Feel free to email me if you want to keep it private.

What's your email? I'm<EMAIL_ADDRESS>

<EMAIL_ADDRESS>(you can view it on my github profile :smiley:)

Updating this with info from our email thread:

Seems like the second time we try to use the following, we get weird vertex issues on any other Graphics objects:
  arcCircle.lineStyle(10, color);
  arcCircle.moveTo(CIRCLE_RADIUS + 2, CIRCLE_RADIUS + 2);
  arcCircle.arc(CIRCLE_RADIUS + 2, CIRCLE_RADIUS + 2, CIRCLE_RADIUS - 8, 0, targetRadians, false);

It seems like drawing a path, which is not a polygon, that is, it doesn’t close. Is generating or losing some vertexes. Or maybe it’s trying to autocomplete the path in WebGL and losing track.
Maybe that massive vertex array in WebGL becomes off by one?
No idea. I can get you a reproducible case later this week. For now, we’re just going to make an animated bitmap sprite sheet to work around it.

Thanks, Chad. That's interesting. We also tracked it down to the circle, and are now using a sprite sheet workaround rather than drawing an arc. :)
Thanks again for looking into it!

@alexmahan Just so we are clear, that was a copy-paste of what @tdreyno sent me the other day. Not my words :)

Bump for a repro case :D

Still cleaning up after our launch (https://events.google.com/io2015/?experiment), will post this when we get a free moment.

I'm curious if you try this with the new v3 stuff if you still get that issue? Graphics got an overhaul in that branch and I'm curious if this issue is still happening there or if it can be closed.

We'll be open sourcing the code soon. But won't be able to spend time porting it to v3. Feel free to close this ticket.

I'm getting that same error in v3.0.7.  It mostly happens when I leave the tab alone for a while and come back to it.  I use drawCircle a lot.


Fluent logger uses caller attributes but non-fluent not

from https://github.com/NLog/NLog/issues/768

As a side remark, it's a bit weird that the fluent API includes caller info like this but the regular one doesn't. You might want to think about how to harmonize this behavior across the board

We should fix this, because it's inconsistent.

Does anyone have any ideas how to fix this? (@gab ?)

After #2386 has been implemented, then it is a matter of removing the artificial callsite-LogEventInfo-properties.


chore: Fix typo in vite docs

Fixed formatting now @AbhiPrasad!

We also need to fix this in the other readmes.


Determine how to best include BioPerl modules that have been moved to their own releases

As had been planned for a long time, many BioPerl modules have now been moved to their own repositories and will (presumably) be under independent release schedules. By default, they won't be included in the container.
From here two approaches are possible:

Leave it to users of the container image to add modules that they need.
Try to stay consistent with the original driving use-case and include as many BioPerl modules as possible.

Feedback welcome. Right now, the default is (1).

If the target of the docker is to provide:
@hlapp wrote in issue #5:

A reproducible, documented, versioned, and ready to use BioPerl installation.

then I think it more sense to include all of the BioPerl project distributions. The reproducible and versioned points would require (unless the end user really only needs the BioPerl core distribution --- which is getting increasingly small), a docker with all the distributions that the end user needs.
You said it yourself, "stay consistent with the original driving use-case". If you go with 1), then this project would need a new purpose.


SWARM-1206: Provide a way to set @ApplicationPath value in WildFlySwarmDefaultJAXRSApplication

[x] Have you followed the guidelines in our Contributing document?
[x] Have you created a JIRA and used it in the commit message?

https://issues.jboss.org/browse/SWARM-1206

[x] Have you checked to ensure there aren't other open Pull Requests for the same issue?
[x] Have you built the project locally prior to submission with mvn clean install?

Motivation
It'd be useful enabling to change @ ApplicationPath value
in WildFlySwarmDefaultJAXRSApplication via yml.
Modifications

Add @ Configurable("swarm.deployment.*.jaxrs.application-path") to set the ApplicationPath value
Move the place to generate WildFlySwarmDefaultJAXRSApplication into DefaultApplicationDeploymentProcessor
Add an integration test in testsuite-jaxrs

Result
You can change @ ApplicationPath value via yml.

@emag Looks like this requires a rebase

Hi @emag just wanted to see if you had an idea of when you might be able to take a look at fixing up this PR?
Thanks

@kenfinnigan I'm so sorry for late response about this P-R. I'll work on this next month(after RH Summit).

Not a problem, I know we're all busy right now

So, this is quite out of date with the @DeploymentScoped and DeploymentProcessor changes.

@bobmcwhirter Thank you for your reply. yeah, I'm working on this with @ DeploymentScoped and DeploymentProcessor instead of ArchivePreparer. And I'm introducing wild-card configurable property name like;
    @AttributeDocumentation("Set the JAX-RS application path, if the JAX-RS application class is autogenerated by Swarm")
    @Configurable("swarm.deployment.*.jaxrs.application-path")
    Defaultable<String> applicationPath = Defaultable.string("/");

I've updated this PR. Please review.

retest this please


Add new rule to prevent nested list footgun

Hello.
I don't really work with nested lists but I know that it's quite common among the sci community (in fact I'm opening this issue after seeing this tweet).
I dug into the tracker to see if it was suggested before, but I could not find anything. I forgot to record what I tried, though.
Anyway, here is an excerpt of the issue:
# It might not be intuitive that the lists inside are actually the same
# It is very likely not to be intended, and a footgun all the time
foo: list[list[int]] = [[]] * 4

foo[0].append(42)

print(foo)  # [[42], [42], [42], [42]]

It's quite silly and experienced Python programmers usually don't fall for it, but people for whom coding is not their main activity and/or beginners can and do.
This rule could also be extended to passing a list literal as the second argument of dict.fromkeys, although this might be considered out of this issue's scope.
(+ I don't know by heart all the places where this "lists that actually share the same memory" footgun appears, but feel free to list some more.)

Happens for all kinds of mutable, so we could add rules for those included:
foo = [set()] * 4
foo[0].add(42)
print(foo)  # [{42}, {42}, {42}, {42}]

bar = [{}] * 4
bar[0]["a"] = 42
print(bar)  # [{'a': 42}, {'a': 42}, {'a': 42}, {'a': 42}]

Dang it, I missed this discussion. I really am terrible at searching up.
But yeah, of course, any mutable non-scalar object should be included.

I think it might be pretty hard to detect dangerous examples of that with high precision. Looking at https://grep.app/search?q=[[]] *&case=true&filter[lang][0]=Python there are plenty of usages, but they all look fine.
Someone needs to do
foo[0].append(bar)

to make it a real footgun.


ARTEMIS-1031 Fix prefix support

@clebertsuconic This removes a bunch of code you added to strip prefix from the address.  Was there a reason to do this?  We don't change the send address for prefixes.  Client will receive "multicast://foo" for example.  We add the proper address to the RoutingContext but leave the message as is.

@mtaylor non intentional. it was probably some gitfu before as I was rebasing against my branch.


Issues found from Inferno Kit

AdverseEvent sample Resource

"AdverseEvent/de-identified-example: AdverseEvent.category[0].coding[0]: Unknown Code http://terminology.hl7.org/CodeSystem/adverse-event-category#medication-mishap in http://terminology.hl7.org/CodeSystem/adverse-event-category for 'http://terminology.hl7.org/CodeSystem/adverse-event-category#medication-mishap'"
The above error states that the locally run version of the test kit cannot validate the adverse event coding terminology. Until the merge is complete, we cannot verify whether or not it can be validated by the hosted server. Should the package file supplied by UDS+ IG provide proper validation for this code set? We must decide whether to make workarounds within Inferno kit to address this, or if a package update is needed.
AdverseEvent/de-identified-example: AdverseEvent: AdverseEvent.text: max allowed = 0, but found 1 (from http://fhir.org/guides/hrsa/uds-plus/StructureDefinition/uds-plus-adverseevent|1.0.1)
The adverse event resource contains a text field, whereas the structure definition forbids any text fields. Either the structure definition needs to be updated, or the sample needs that text field removed,

Allergy Intolerance sample resource

AllergyIntolerance/de-identified-example: AllergyIntolerance: AllergyIntolerance.text: max allowed = 0, but found 1 (from http://fhir.org/guides/hrsa/uds-plus/StructureDefinition/uds-plus-allergyintolerance|1.0.1)
The Allergy Intolerance resource contains a text field, whereas the structure definition forbids any text fields. Either the structure definition needs to be updated, or the sample needs that text field removed,

Errors seem corrected


fixunsupported hive input format should throw an exception and remove useless method.

Proposed changes
introduce from: https://github.com/apache/doris/pull/28644

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


Also catch Perma-failure and be more generic for Bustage

Example: https://bugzilla.mozilla.org/show_bug.cgi?id=1485369

Coverage remained the same at 48.629% when pulling c98f0164be36ca3eaa510b5069fc73922294ee2b on sylvestre-patch-6 into 19634af155d22420d8fc017d12da8239559a72f8 on master.


Add currency validator

As per suggestion, based the isCurrency validator on isMobilePhone, but used currency codes instead of locales because it seemed more reasonable, for example, to have a EUR validator that covers some slight variations instead of using all locales in the eurozone separately. Reliable information on formatting conventions seems difficult to find, so I based the RegEx's on ASP.NET/C# formatted strings with various CultureInfo instances. Added mocha tests as well.

Coverage decreased (-0.27%) to 97.17% when pulling 3a19a0caf54101ca17c1094f699e8941ba0219e8 on regularmike:master into bab1c14fbc5b80677a985fa987a7f625dd8901f4 on chriso:master.

Coverage decreased (-0.27%) to 97.18% when pulling 268f3d0eb1036642a26b64b90cc3795c26ef510d on regularmike:master into bab1c14fbc5b80677a985fa987a7f625dd8901f4 on chriso:master.

Looks like some of these match empty string and the currency symbol by itself. Need to add some lookaheads, perhaps. Will update soon. I know I've been a bit overeager.

I think this is fairly solid now. Added more tests for edge cases like the ones you mentioned and a fixed a few others that I found like solitary currency symbol, empty string, and single space. Have a look when you get a chance.

Coverage decreased (-0.27%) to 97.18% when pulling 0dd86112ffaa33779cc2ce90aab78e8961774e89 on regularmike:master into bab1c14fbc5b80677a985fa987a7f625dd8901f4 on chriso:master.

Thanks. Couple more edge cases I found:

$- => true
- => true
$10,123 => false

What about this?
/^(?!\$?\-?$)\$?\-?([1-9]\d{0,2}(,\d{3})*|(0|([1-9]\d*)?))(\.\d{2})?$/

Coverage decreased (-0.27%) to 97.18% when pulling 59f6cbb066f01432626350bf636ec822d81292df on regularmike:master into bab1c14fbc5b80677a985fa987a7f625dd8901f4 on chriso:master.

Well, two edge cases and one glaring typical case. Man, it's been a while since I've done any non-trivial regular expressions. Your version looks good. Adjusted the others accordingly, and added those test cases and other similar ones for all currencies.

Two more: '-  €', '-€'. Almost there :wink:
That euro one is getting quite complicated. Do they really accept the currency symbol on either side?

Nice catch. Unfortunately they do accept it like that in certain places. I
was looking at the ones in the mobile phone list in C#, which had some
slight variations, so I looked into it more. This page doesn't match what
.NET is doing exactly, but I think it shows all the cases that we are
trying to cover:
http://www.evertype.com/standards/euro/formats.html
Testing in C# confirms that the euro sign can be on either end, but I
haven't actually seen one that doesn't use a space before the currency
symbol at the end.
10123.25.ToString("c", new CultureInfo("el-GR")) => 10.123,25 €
10123.25.ToString("c", new CultureInfo("fr-FR")) => 10 123,25 €
10123.25.ToString("c", new CultureInfo("en-IE")) => €10,123.25
10123.25.ToString("c", new CultureInfo("it-IT")) => € 10.123.25
At this point I'm thinking it would be better to do this by
language/culture string like the mobile phones. It might seem more natural
to use USD than en-US, but I think each regex would become easier and more
reliable. I imagine you're having the same thought. However, if we do that
it seems like we should make the list much more comprehensive, at least
including all the eurozone countries. Should we include any others that we
haven't already?
On Thu, Feb 26, 2015 at 8:38 AM, chriso<EMAIL_ADDRESS>wrote:

Two more: '- €', '-€'. Almost there [image: :wink:]
That euro one is getting quite complicated. Do they really accept the
currency symbol on either side?
—
Reply to this email directly or view it on GitHub
https://github.com/chriso/validator.js/pull/368#issuecomment-76178909.

An even better alternative might be to generate the regex based on user input.
Something along the lines of
function currencyRegex(options) {
    var symbol = '\\' + options.symbol + '?'
      , negative = '\\-?'
      , amount_without_sep = '[1-9]\\d*'
      , amount_with_sep = '[1-9]\\d{0,2}(\\' + options.thousands + '\\d{3})*'
      , amount = '(' + ['0', amount_without_sep, amount_with_sep].join('|') + ')?'
      , decimal = '(\\' + options.decimal + '\\d{2})?$'
      , prefix = symbol + negative;
    return new RegExp(
        '^' +
        '(?!' + prefix + '$)' + // ensure there's an amount and/or decimal
        prefix +
        amount +
        decimal +
        '$'
    );
}

validator.isCurrency = function (str, options) {
    return currencyRegex(options).test(str);
}

validator.isCurrency('$10,123', {symbol: '$', thousands: ',', decimal: '.'});
// => true

It's then quite easy to customize the validator. For example, you could add an option to allow whitespace, another to require a currency symbol and another to exclude negative values. You could also default each option to USD, since many locales share the same parameters.

I like this, as long as there is no significant demand for validating
without having any knowledge of the format. And I suppose there may not be.
This seems like the most flexible solution so far. I'll keep the current
tests, more or less, but just arrange the appropriate validator before each
set.
The msdn article you originally referenced also points out that the
negative sign could be before or after the currency symbol, or even after
the digits, but of course the default will be at the front of the string so
most users won't have to specify that option. We should also support
parentheses for negatives since it's the preferred format for financial
applications in the US. Not sure if that should be the default, though.
Will let you know when I have the tests working with this solution. Thanks.
https://msdn.microsoft.com/en-us/goglobal/bb688126.aspx
On Thu, Feb 26, 2015 at 8:56 PM, chriso<EMAIL_ADDRESS>wrote:

An even better alternative might be to generate the regex based on user
input.
Something along the lines of
function currencyRegex(options) {
var symbol = '\' + options.symbol + '?'
, negative = '\-?'
, amount_without_sep = '[1-9]\d*'
, amount_with_sep = '[1-9]\d{0,2}(\' + options.thousands + '\d{3})*'
, amount = '(' + ['0', amount_without_sep, amount_with_sep].join('|') + ')?'
, decimal = '(\' + options.decimal + '\d{2})?$'
, prefix = symbol + negative;
return new RegExp(
'^' +
'(?!' + prefix + '$)' + // ensure there's an amount and/or decimal
prefix +
amount +
decimal +
'$'
);
}
validator.isCurrency = function (str, options) {
return currencyRegex(options).test(str);
}
validator.isCurrency('$10,123', {symbol: '$', thousands: ',', decimal: '.'});// => true
It's then quite easy to customize the validator. For example, you could
add an option to allow whitespace, another to require a currency symbol and
another to exclude negative values. You could also default each option to
USD, since many locales share the same parameters.
—
Reply to this email directly or view it on GitHub
https://github.com/chriso/validator.js/pull/368#issuecomment-76316936.

Coverage decreased (-0.09%) to 97.35% when pulling 15122c2414496cb9beeea19d31b75c78afc149c8 on regularmike:master into bab1c14fbc5b80677a985fa987a7f625dd8901f4 on chriso:master.

OK, I've implemented it in the new, customizable way. A few things to note:

Default is en-US format but with negative sign instead of parens. Parens is the standard for display but for entry I think negative sign is more appropriate.
One of the options I came up with was allow_negative_placeholder, which means a space is allowed only for a non-negative value, which I noticed is how the South African Rand (en-ZA) is formatted, e.g. R 123 but R-123
That msdn article shows Netherlands euros (nl-NL) with the negative sign after the digits. I don't think that's the official format, and .NET is not doing it that way currently. This option is still supported (negative_sign_after_digits) but might not be needed by anyone as far as I can tell.
No more than one consecutive space is ever allowed anywhere, and when a space is allowed it's always optional. Not sure if it would be worth adding an option for enforcing that space.
Tried to be pretty thorough with tests but there is now a huge number of combinations of options. I think we have the most common ones covered, but anyway I think it would make more sense to look at formats that may not be similar to any of the ones listed below (if there are any) than to try to test a large number of arbitrary combinations.
Finally, once this is ready I'll be happy to squash commits and send a cleaner pull request, but I figure it might take some more passes.

UK: -£10,123.25
Ireland: -€10,123.25
Italy: -€ 10.123,25
Greece: -10.123,25 €
France: -10 123,25 €
Australia: -$10,123.25
China: ¥-10,123.25
South Africa: R-10 123,25
Denmark: kr. -10.123,25
Netherlands: € -10.123,25
US: ($10,123.25)
CA: -$10,123.25

Looks great, thanks :+1:
Want to clean up the commits and then I'll merge?

Coverage decreased (-0.09%) to 97.35% when pulling e9a4701e21db646e41b64e280f515622cb94b177 on regularmike:master into bab1c14fbc5b80677a985fa987a7f625dd8901f4 on chriso:master.

OK, all set. Also updated README.

Coverage decreased (-0.09%) to 97.35% when pulling 8364c1291a95f69b2aca2580018e85f0f6cba7e6 on regularmike:master into bab1c14fbc5b80677a985fa987a7f625dd8901f4 on chriso:master.

Perfect. Thanks again.

Available in v3.33.0.

No problem. It was very educational. And happy to contribute to something I use all the time. Here to help if  anybody brings up anything that we overlooked.


Handle trailing slash on dirs

something like /thing/thing will work but /thing/thing/ looks for /~/.


Capture Window: Accessibility basics

Introduces the accessibility interface to be used for controls beneath
the OrbitGlWidget, and unit tests where possible. The interface is
implemented for GlCanvas in this PR, but returns 0 valid children.
Functionality for GlCanvas, TimeGraph and Tracks will follow in a
subsequent PR.
For documentation, check OrbitQt/AccessibilityAdapter.h.

Thanks for the review, @dpallotti and @pierricgimmig. I've addressed all of your comments and resolved the ones that didn't require any discussion. There's a few with which I disagree, I've commented and left them open, PTAL.
There's a lot of small fixup commits now since I needed to work through this in small chunks, sorry for that, but I want to avoid rebasing so you can see your changes since the last review.

Also, I'm wondering if the "Accessibility" nomenclature is the right one in OrbitGl. If we end up using this system for selection/picking for example, it would be weird to go through "Accessibility" classes rather than a more generic "Bounding Box" hierarchy. Could "Accessibility" be an "OrbitQt" only concept that would use geometry information gathered from OrbitGl? We can discuss this in person. That being said, I'm happy to submit as is and iterate if need be.

We can discuss that in person. But note that this is more than just bounding boxes - this also contains parts which are specific for the Microsoft UI Automation API (which Microsoft lists under the umbrella term of Accessibility: https://docs.microsoft.com/en-us/dotnet/framework/ui-automation/), like the control types and states, and it could actually be extended later to provide more accessibility features like tabstops, text for screenreaders etc, if we'll make this a priority.
I agree that a general concept of hierarchy and positioning would make sense in our GL Widgets, but then I'd go at it the other way around: Extend our classes with this general interface (sort of a super-simplified QWidget), and have the accessibility-classes use this.

I'm just going to say this: Have you at least considered putting this functionality in separate modules (I guess it would have to be one for Gl and one for Qt which is unfortunate). It seems to me that you are trying to keep everything in the same file to not add too much to the existing modules. Instead, this seems to be new functionality that doesn't really depend on the rest of the module. You could (maybe) have Gl depend on GlAccessibility, Qt depend on QtAccessibility, and QtAccessibility depend on GlAccessibility.

As discussed yesterday, I split this into a separate module OrbitAccessibility (decided to leave out the "Gl" as this is not OpenGl-specific and could be used if we support a different UI framework as well).

Split into AccessibilityInterface, AccessibilityInterfaceRegistry, and AccessibleWidgetBridge, each of them in their respective header files
Tests now live in a separate module OrbitAccessibilityTests
OrbitGl and OrbitQt both depend on the new module
AccessibilityAdapter still lives in OrbitQt as it is Qt-specific

Adjusted namespaces and include guards correctly, and added all headers to the makefiles (hope I didn't miss anything).


New feature: display tflite metadata

Hi @lutzroeder! Thanks for creating this project, it's extremely useful. I was wondering if you're interested in adding support for tflite metadata buffer interpretation (or accept contributions). More specifically, I'm interested in offline planned buffer metadata. Some background:
https://docs.google.com/document/d/16aTSHL5wxsq99t6adVbBz1U3K8Y5tBDAvs16iroZDEU/edit
Cheers!
Fredrik

@freddan80 can you provide some more context. Is this a feature that is supported in TensorFlow Lite  and the current TensorFlow Lite engine or is this a proposal that you are planning implement for another engine? How would this information surface if supported in the UI? Is there official documentation for the officially supported TensorFlow Lite metadata properties?

@freddan80 can you provide more context:

Is there official documentation enumerating valid TensorFlow Lite metadata properties?
It's only the RFC document above for now.
Sample files using metadata?
We can arrange a sample .tflite file.
Is OfflineMemoryAllocation officially supported and implemented in the current engine?
There's a PR for it currently. The RFC is approved though. Note that the functionality will only be supported the TFL for microcontrollers runtime, for now.
How would this information surface if supported in the UI?
We'd have to look into this, but I'm imagining a 'Metadata' field under model properties, that is expandable to display the relevant info.

Currently, I'm just exploring if there would be an interest in having this feature. I believe there'll be a big demand for this feature eventually, since it used by our ethos-u55 tools (see https://developer.arm.com/ip-products/processors/machine-learning/ethos-u55).
Cheers!

Let's circle back when there is some more clarity and this becomes part of the format standard. Adding an expander for metadata is an option, higher priority would probably be adding standard fields like description or author or license (see Core ML or ONNX). Looks like TensorLite Lit is trying a different approach metadata_schema.fbs.

Let's circle back when there is some more clarity and this becomes part of the format standard.

I'm not sure the format will ever be a part of schema.fbs, since the metadata buffer format is user defined.

Adding an expander for metadata is an option. It would have to be done in a way that keeps the UI simple, maybe similar to tensor initializers.

Agree. This is key.

Looks like TensorLite Lite is trying a different approach metadata_schema.fbs.

I'm not sure what that experimental branch is actually for, but I'll check it out. Thanks! The offline planned tensor implementation is following this format:
https://github.com/tensorflow/tensorflow/blob/2d3828de27879655cc126bc2bb932de299b5153c/tensorflow/lite/schema/schema.fbs#L1056

The main challenge here is probably keeping a balance between maintenance cost vs. walking down every experimental fork of the dozens of similar ML formats out there.

Absolutely agree! We can have a more detailed discussion when it's time.
Cheers!


Color management

Actually, we have sectioning color defined with \definecolor (in HTML). Should we make the same for links color and blocks color (attention, etc.) ? It will make #7 easier.

Definitely a good idea. Do I assign you ?

OK.


Provide link to settings files

Provide link to settings files / suggestions for which settings are the ones to be careful of to avoid frying the controller.

I don't have any specific knowledge of which settings to be careful with. There are many posts online about these settings, and I suggest searching there instead.

Understood.
My experience is the same-everytime I tweak settings I spend a while searching online for advice. In the same way as your software makes it much quicker & easier to reprogram the motors, adding some links to posts with settings info can make finding the information easier.
I wanted to label this as 'gold plating' because its a nice to have not a problem or bug.
Thank you for the program :)

Feel free to provide a list of links to such useful pages about the settings, and I can include it in the README here :)


feature: allow tracking of custom depot paths

Scenario
Some users use a custom depot path for Julia using the JULIA_DEPOT environmental variable.
Rationale
Regardless of the reason, juliaup should track custom depot paths to allow flexible configuration and managing of julia versions on customized setups.
Use cases

Self uninstalling of ~/.julia/juliaup and custom depots e.g. $JULIA_DEPOT/juliaup as mentioned in https://github.com/JuliaLang/juliaup/issues/457
A saved data (maybe as JSON?) of tracked custom depots for users to clean up for uncommon cases such as a broken juliaup installation.
Customized setups where littering the HOME directory is not desirable.

We still have this issue not resolved then https://github.com/JuliaLang/juliaup/pull/661 so this is a braindump for now until that's done.

I don't really understand what the proposal actually is. What do you mean by "tracking"? I think this just needs more explanation of what you actually have in mind :)


Use partial(next, ...) instead get_next()

Since jinja2 doesn't support any version older than Python 2.6 anymore, we can simply use the next built-in function rather than abstracting it.__next__ (Python 3) and it.next (Python 2) ourselves.

LGTM

Since I'm not a committer, and you seem to approve this change, mind merging it? (Same for my other PRs where you gave LGTM)

I'm the least-experienced maintainer on the team, so if I review a PR and think it looks good but that there's a chance I might be unaware of why something is the way it is, I just give a LGTM.
So far that's worked pretty well, sometimes it gets merged directly by one of the other maintainers, sometimes someone chimes in with more background on why something is a particular way. But generally those PRs get a second look.
BTW, I know many of these PRs/issues just sat for a while, but we're making consistent progress on the backlog now that we moved to pallets. If you're still interested in helping out on the project, we'd certainly appreciate your help tackling some of the thornier issues like #19 and #298

Fine with me. I didn't meant to urge you. It just wondered why a maintainer gives LGTM, without merging the change or any further comment. Anyway, thanks for moving things forward here.

https://github.com/pallets/meta/issues/14 :wink:

I'm going to go ahead and merge this.


Improve UI testing

Currently, only very basic Zooming APIs are tested through mocha in browser. We should probably include some end-to-end tests by leveraging a web automation framework.
awesome-test-automation

Try TestCafe.

Seems long press in testcafe is not supported...See this issue.

cypress runs tests directly in the browser, it looks very promising!

Having trouble simulating long press. The following code does not zoom the image further in:
describe('Demo Page Test', function () {
  beforeEach(function () {
    cy.visit('/index.html')
  })

  it('Opens and closes the first image', function () {
    cy.get('#img-default')
      .click()
      .wait(1000)
      .trigger('mousedown')
      .wait(1000)
      .trigger('mouseup')
      .wait(1000)
      .click()
  })
})

Figured out:

describe('Demo Page Test', function () {
  beforeEach(function () {
    cy.visit('/index.html')
  })

  it('Open, grab, release and close the image', function () {
    cy.get('#img-default')
      .click()
      .wait(500)
      .trigger('mousedown', { button: 0 })
      .wait(500)
      .trigger('mouseup', { button: 0 })
      .wait(500)
      .click()
  })
})

@kingdido999 Recently, Ive been playing with Cypress as well. What button: 0 means actually? Didnt find any info about in docs. Thanks and sorry for offtopic.

@mahish In this case, it means main/left button on input device (mouse, track pad, .,etc). You can find more details here.


feat: docsearch feature

Should close https://github.com/nuxt-community/algolia-module/issues/41
This is an initial implementation ported from the PR mentioned in the issue. 🙂
I hope we can work on this together for further steps!
Types of changes

[ ] Bug fix (a non-breaking change which fixes an issue)
[X] New feature (a non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description
In this branch, you can start the playground to see how the default component works!
I've added a toggle option on the config to disable/enable the component injection.
Things that seem missing:

[x] Configuring the DocSearch module from algolia key in nuxt.config
[x] Configuring the styling easily (theming from config?)
[ ] Default theme for Nuxt 💚
[x] Updating documentation to include the new feature

Checklist:

[X] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes (if not applicable, please state why)

@Tahul
Regarding your points:

Configuring the DocSearch module from algolia key in documentation // Could you elaborate on that? I dont think that I understand.
Configuring the styling easily (theming from config?) // For that we could use colors in theme config (like primary/secondary)
Default theme for Nuxt 💚  // I think we should offer the Nuxt theme by default to the search component
Updating documentation to include the new feature // I will take care of that

Configuring the DocSearch module from algolia key in documentation

It was a typo 😄, I meant configuration! You are discussing about this in next points.

Configuring the styling easily (theming from config?) // For that we could use colors in theme config (like primary/secondary)

What do you mean by theme config ?

I think we should offer the Nuxt theme by default to the search component

Sure, I talked about theming because that should be a feature of that integration, shipping with default theme but having a way to add theme presets would be great imo. 🙂

Updating documentation to include the new feature // I will take care of that

Thank you a lot 🙏

I will work on your reviews points this week and try to get it ready!
Thank you for your feedback @Baroshem 😄

Hey @Baroshem 😄
Updated the feature! It should be fine now.
I also wrote the documentation, let me know if anything is unclear.
Thanks for your feedback and reviews! 🙏

Also, I decided not to ship any default theme for Nuxt but instead include a Theming section in the docs.
I don't think having a custom theme by default is what we expect from such kind of feature.
Having the default Algolia theme by default seem more reasonable to me.
Will implement the Nuxt Theme from v3.nuxtjs.org or websites that needs it!

Hey @Tahul
Thanks for the improvements! I will check them out in the upcoming days and I will make sure to merge them next week with a new version of the module 😉

@yassilah
Could you please take a look at it? :)

Hey @Tahul
Would you be able to add the changes proposed by Yassilah? I would like to release a new version of the module with these changes :)

Hey @Baroshem ; really sorry for the late answer, completely missed the notification!
Pushing that right now. 😄

(@Baroshem ; it's done, maybe @yassilah needs to review it one more time! 🙏)

Hey @Tahul
Sure, lets wait for final vote from Yassilah. Also, I would need some time tomorrow for proper testing snd we could release the new version later 😉


Remove dependency on npm for CADL compiler / emitter in nuget package

microsoft.azure.autorest.csharp nuget package contains all the packages required to generate code from swagger, without any dependency on npm or npx, e.g.:
node C:\path_to_packages\microsoft.azure.autorest.csharp\3.0.0-beta.20220712.1\tools\autorest\entrypoints\app.js --max-memory-size=8192 --skip-csproj --skip-upgrade-check --version=3.8.4 C:\GitHub\azure-sdk-for-net\sdk\confidentialledger\Azure.Security.ConfidentialLedger\src\autorest.md  --use=C:\path_to_packages\microsoft.azure.autorest.csharp\3.0.0-beta.20220712.1\tools\netcoreapp3.1\any\ --clear-output-folder=true --shared-source-folders="C:\GitHub\azure-sdk-for-net\sdk\core\Azure.Core\src\Shared\;C:\path_to_packages\microsoft.azure.autorest.csharp\3.0.0-beta.20220712.1\content\Generator.Shared\" --output-folder=C:\GitHub\azure-sdk-for-net\sdk\confidentialledger\Azure.Security.ConfidentialLedger\src\Generated --namespace=Azure.Security.ConfidentialLedger

We need to have similar independence for the CADL case.

Two difficulties here:

Autorest is js-based without any other languages. So it could be packed into a single executable by webpack. However, cadl is not because it contains cadl-related libraries.
Cadl itself doesn't know the existence of CSharp emitter.

@pshao25,  cadl should be similar to autorest,  for CADL, you just need pack  @cadl-lang\compiler and invoke
node 'cadl path'\compiler\cmd\cadl.js
Other dependencies should be put together with CADL files and we don't need to put it together with nuget.

What is the use case for this?

@AlexanderSher
Th difference between a compiler and a tool is: the autorest tool could automatically look for the .net codegen plugin and call it, while compiler cannot do this. The expectation to use cadl compiler is: user provides the cadl spec and a package.json to indicate the compiler version and library version. The libraries should be loaded locally, so we could not pack them (and codegen doesn't know which to pack). The compiler itself could be packed but it is a meaningless thing, because it is the user who indicate its version.
According to above, the best solution to me now is: we could pack the emitter and its dependencies into a single file (as waht we did in https://github.com/Azure/autorest.csharp/pull/2761), and release the bundle file in our nuget package. Then user could generate code by:

install the compiler and libraries they want.
run npx cadl compile {cadlFile.cadl} --emit bundle.js --output-path Generated\
run dotnet AutoRest.CSharp.dll --no-build --standalone Generated\

We have put the codegen and emitter (with its dependecies) into the package. The things that not covered in package now is only the compiler and libraries. But users still need to provide Configuration.json (or we could generate it).

Duplicate of https://github.com/Azure/autorest.csharp/issues/2585


Azure Devops Warning

Had a new Azdo warning show up today.  I believe this is task related (not TF itself).
##[warning]%25 detected in ##vso command. In March 2021, the agent command parser will be updated to unescape this to %. To opt out of this behavior, set a job level variable DECODE_PERCENTS to false. Setting to true will force this behavior immediately. More information can be found at https://github.com/microsoft/azure-pipelines-agent/blob/master/docs/design/percentEncoding.md

Not sure what impact this will have, but wanted to share just in case it's going to be a problem.

Since we are well into march and there has been no issues reported related to this, I do not believe any action is necessary at this time. Thanks @treyhendon for reporting this. Will revisit if issues begin to surface around the encoding.


Common searches for finding relevant issues/prs

@betterscientificsoftware/bssw-content-reviewers could benefit from a markdown file with a series of annotated common searches so they can more easily find different categories of things. Lets identify here some of the common search we need (whether or not GitHub directly supports it via their search syntax) and once we have enough, start developing the markdown file and/or conventions in the use of comment keywords to implement them.
@rinkug was describing difficulty in finding items that did not have a milestone for example.

Overdue content
Missing milestone
2 or more up votes (or a net of 2)

I think @markcmiller86 's suggestion is a good one.
However, what I think would be really cool and useful is if we had some bots looking out for some of these things.  I amused myself a while back googling for some info for GitHub bots.  There are numerous examples, and a framework for writing bots.  Nothing is quite what we want, but things were close enough that I'm pretty confident that it would not be a huge matter of programming to create bots that do do what we want.
https://probot.github.io/
https://probot.github.io/apps/stale/
https://probot.github.io/apps/reminders/
https://probot.github.io/apps/minimum-reviews/
https://github.com/apps/top-issues

I am adding below to what Mark listed (Overdue content, Missing milestone, 2 or more up votes (or a net of 2)).
We need to define what a milestone is being used for. Looks like its only relevant for bssw-digest?
This is a starting list:

What items have been already published on BSSw.io  but are not part of any monthy digest (A useful additional search parameter: date range, month names, year names,)
What items have published on BSSW.io  in a certain time frame  (search parameter: date range or labels such as last month or last year)
What items have been included in BSSW.io Digest in a certain time frame
4 . What items are under-works but will never be a part  of monthly digest but should be done on a deadline (ex: updates to existing articles)
What items are of interest for the future, but we have no resources for them right now
What items are of interest by a specific date, but we have no resources for them right now

I am adding below to what Mark listed (Overdue content, Missing milestone, 2 or more up votes (or a net of 2)).
We need to define what a milestone is being used for. Looks like its only relevant for bssw-digest?
This is a starting list:

What items have been already published on BSSw.io but are not part of any monthy digest (A useful additional search parameter: date range, month names, year names,)
What items have published on BSSW.io in a certain time frame (search parameter: date range or labels such as last month or last year)
What items have been included in BSSW.io Digest in a certain time frame
What items are under-works but will never be a part of monthly digest but should be done on a deadline (ex: updates to existing articles
What items are of interest for the future, but we have no resources for them right now
What items are of interest by a specific date, but we have no resources for them right now

Here is a search for all issues with less than 3 reactions (of any kind) which appear on the Content Development project board...
is:issue is:open reactions:<2 project:betterscientificsoftware/betterscientificsoftware.github.io/3
Project boards are identified by repository path and number. The magic number 3 for the project board is determined by going to the project board and looking at the number at the end of the URL.
It would be nice if the search could be for a specific column of the project board. But, that doesn't seem to be possible.

Unfortunately, the reactions search doesn't seem to work as a filter in the project board itself.  That seems like a misfeature.

Reading here we can at least do some sorting by reactions
is:issue is:open project:betterscientificsoftware/betterscientificsoftware.github.io/3  sort:reactions-+1 sorts in descending order of thumbs ups.

Another is to sort in descending order of the most thumbs down...
is:issue is:open project:betterscientificsoftware/betterscientificsoftware.github.io/3  sort:reactions--1 sorts in descending order of thumbs ups.
These aren't exactly what we want but they get us closer.  Maybe best we can hope for.

This is a starting list:

What items have been already published on BSSw.io but are not part of any monthy digest (A useful additional search parameter: date range, month names, year names, etc.)
What items have published on BSSW.io in a certain time frame (search parameter: date range or labels such as last month or last year).
.
.
.

Sorry @rinkug I guess I missed this. So, the only challenge I see with your list is that many of them involve knowing if something appears in the digest and/or is already published on bssw.io. I don't know that we can use standard GitHub issue/PR searches to answer these questions because it requires knowledge from non-GitHub sources (e.g. the digest and what is already published).
Perhaps if we either manually (or via bots as David proposes) added labels to items that have been included in a digest or published, that would facilitate your needs here. Or, instead of labels using some conventional comment text we can filter on.
I will see about your other cases.


Link to Karma plugin

In case anyone's interested I've written a Karma plugin for this great little package: https://github.com/alexweber/karma-sinon-stub-promise
Would be nice if maintainers linked to it in README... :)
Thanks!

Can you explain this plugin? We use sinon-stub-promise with karma without a plugin.
I'm just curious.

@astephenb I guess the main point is wrapping sinon-stub-promise in a proper Karma plugin so it can be added to frameworks & plugins as usual and not require you to manually add anything to files:[] for it to work... presumably that's how you're using it?

Cool. Go ahead and make  PR, I can merge when I get a chance.

:+1: Thanks!


Add missing word

Found typo in the first paragraph under the Copy the files to your account section

Thank you!


Unsupported system-specific functionality - compile-time or run-time error?

Crystal has been gaining support for different platforms, but some functionality is not available on all platforms. Regardless of the outcome, such things should definitely be stated in the documentation. But a decision should be made between one of the two options:

Unsupported functionality is a compile-time error:
This is probably the obvious first thought for most people, because it clearly and immediately lets you know that your code uses some functionality that's not supported on the platform of choice. But on the other hand, it makes Crystal's public API "unstable" -- you can't rely on a method always being there if it's in the documentation. More importantly, it is impossible to use this functionality only on supported platforms, with a fallback for others. Well, technically it is, by duplicating the list of flags for supported platforms in users' code, but it's annoying and not future-proof. Also some functionality may not be available depending on the "run-time" platform rather than the "compilation" platform, so the run-time errors will be there regardless, making this a hybrid with the other option.
I think this is kind of the default that's happening right now.

Unsupported functionality is a run-time error:
Crystal's API is fully platform-independent but the methods that are not supported on a platform will raise (a subclass of?) a NotImplemented error (which is also yet to be defined). Again, this may not seem nicest at first sight, but the reality is that the availability of system features cannot always be determined at compile time anyway, so why not make this at least consistent, and ensure the ability for all Crystal programs to compile on all platforms rather than arbitrarily failing.
I personally prefer this option.

I say it should be a runtime error. Imagine I use a library that in some scenario uses a method that's not available in my platform, but in my specific case, because of some runtime decision (that maybe the library makes) the call will never be made. I don't want the compilation to fail.
I believe every other programming language in the world probably prefers runtime errors in this case too.

This Crystal::System indirection was introduced by @ysbaddaden initially (I'm directly you to be sure you don't miss this issue)

I would definitely prefer if compiler checks as much as possible at compile-time. IMHO it is easier to add workaround if compilation fails, than to discover that something is unsupported in a hard way and then fix it with trial-and-error (if you e.g. don't have an easy access to failing configuration).

I would definitely prefer compile-time errors than runtime errors.
Coming from Ruby and working on improving gems to work on Windows, NotImplemented errors hunted my dreams for years.
Crystal already provides mechanisms to require or skip conditional code depending on the platform, so I would expect a library author or Crystal contributor fence the code around platform specific details, simply failing during compilation with there is no such method x or entirely raise platform unsupported (or something like that).
Cheers.

@luislavena it makes sense , but , thinking about it for a little more time produce this: you cannot cross compile , and you cannot compile code on OSa and use on OSb , it also harms portability , as it means you produce a binery for a system you don't compile on.

Perhaps the best compromise is runtime errors with a static analysis tool which tells you where the platform specific stuff which will raise is in your code.

Imagine this:
# some library provides this:

def do_it(fork = false)
  if fork
    Process.fork { do_some_task }
  else
    spawn { do_some_task }
  end
end

(supposing there's a way to fork in the language)
Now, there's no way to fork in Windows.
Now, I build a program that uses that library where I can configure, via an env var or something like that, whether do_it is invoked in a fork or not.
According to many comments here, when I compile this program in Windows, it should error... at compile-time or runtime?
In my program, the only thing I can do is to read the value for fork from the env var, and then, if we are on windows {% if flag?(:window) %} if fork is true we give a runtime error... there's simply no way to give a compile-time error because I don't know if fork will be true or false at compile time, I only know this at runtime.
Maybe the library should be different and provide two methods: do_it and do_it_with_fork. Or maybe that method is invoked, again, via a configuration option. Of course the library can give a runtime error when trying to fork on Windows, but there's absolutely no way to give a compile error when the functionality is determined at runtime.
I might be missing something fundamental here, but how can we make it, in this scenario, to always give a compile error?

@asterite In this case I think this library was poorly implemented and it should do {% if flag?(:window) %} in its own code. Then it can decide to spawn or raise or whatever. But the problem is that if this method generate a error at runtime, then it will always generate such error.
This argument is pretty similar to "NoMethodError" being a compile-time error instead of a run-time one.

The library just won't compile on Windows, so author (or somebody else) will have to fix it by adding a flag.

@lbguilherme Can you change do_it to use your solution?

do_it, as-is, won't compile on Windows - which is A Nice Thing To Happen™. The shard uses non-Windows code, so it won't work on Windows.
If the author wanted it to work on Windows, it should handle that case - just as you have to handle a nilable variable in your code.
I'd personally change do_it to be:
def do_it
  {% if flag?(:windows) %}
    Process.fork { do_some_task }
  {% else %}
    spawn { do_some_task }
  {% end %}
end

Ideally, I'd love to use {% flag?(:windows) %} inlined with my Crystal code, so I'd only change the if in your version to if fork && {% !flag?(:windows) %} to keep the semantics and allow the caller to choose fork whenever it is available, but it doesn't seem to be supported now. You can do something more verbose:
def do_it(fork = false)
  supports_fork = true
  {% if !flag?(:windows) %}
    supports_fork = false
  {% end %}
  if fork && supports_fork
    Process.fork { do_some_task }
  else
   spawn { do_some_task }
  end
end

@matiasgarciaisaia  That last snippet won't compile on Windows because:
Process.fork { do_some_task }

is not guarded by a flag? check.

Or maybe the library should just ignore the fork argument if it's not on windows.
I'm still not convinced that compile-time errors are the best way to do, but we can try and see if it works. If we find a convincing example that can't be worked-around then we can switch to runtime.

Ideally - for this usecase -  if false or if false && <foo> would be detected by the compiler and be completely removed from the AST but I seem to remember having this conversation prior and deciding that if false shouldn't mask compile errors.

I don't know how to implement this, but Crystal's proposal is "If it compiles, it will somewhat probably work". Deferring the error to run time goes against that.
It may very well be that we find cases in which we can't fail at compile-time for whatever reason, but we should try our bests to get that. Having all that type-safety to avoid NullPointerExceptions just to fail at runtime for an unsupported platform doesn't seem The Crystal Way™.
On one hand, having @luislavena's opinion on Ruby/Windows is a strong signal. On the other, having @asterite thinking otherwise is another strong signal :) So I haven't settled on an opinion yet, but feel compile-time error is the way.

I think it's best to think about what compile time errors actually give us here. If there's a type error in your code, it's a bug and the compiler should error until you fix it. In fact it can't possibly continue without. In the case of platform-specifics, it's not a bug in your code per-se. The most common case for getting an unsupported platform error will be trying something written on unix on windows. In this case it's not a bug in your code, it's a platform incompatibility. So what can you do? In this case you're going to have to add more code to get it to work - and you might not even need the code you're fixing in the first place.
The downside is that you can't be sure whether the executable you just compiled really supports windows or not (really, we should support pretty much everything on both platforms come 1.0), so we should provide a tool which checks and shows you where in your code all the raise NotImplementeds  are.

I think that compile-time checks can work, if the following is done:

Unsupported platforms must be clearly stated in the documentation.
You don't have to manually duplicate the list of flags for supported/unsupported platforms.

{% rescue %} for compilation errors? 🤔

Just my 2 cents: the stdlib does its best to abstract boring platform discrepancies, avoiding the developer to have to deal with them; yet...
If we don't support a feature on some platform (yet), for example Random::System on Windows, I would prefer compilation to fail, not have the impression that it's supported but see it fail at runtime. If a program uses Random::System immediately after starting you'll quickly notice the issue, but what if the call is delayed by some hours? I'd prefer to know that beforehand, at compile time.
Sometimes we just can't support a feature on a given platform. For example fork is unavailable on windows (an maybe other platforms). That's an issue. Maybe:

we shouldn't support fork in Crystal's stdlib —whatever how useful it is, and error prone calling LibC.fork manually can be (and lead to security issues);
we should let Process.fork be undefined on windows, but then platform discrepancies is pushed to the developer. Hopefully, this won't happen much?

Please note that I'd expect to check whether a feature is available rather than maintaining an arbitrary list of platforms to call this or that —just like we don't expect Netscape or Internet Explorer in JavaScript anymore. I'd love a NodeType#responds_to? macro method, to complement NodeType#has_method?, so we could:
{% if Process.responds_to?(:fork) %} # good
  Process.fork {}
{% end %}

Instead of:
{% unless flag?(:windows) %} # bad!
  Process.fork {}
{% end %}

I think we can all agree that explicitly checking for the platform is not good.
The check needs to be universal and conceptually simple. I feel that {% .responds_to? %} does not fulfill that, and it could lead to a chain of feature requests for cases it doesn't take into account. It's also not DRY, so to speak.
I'm being fully serious about a {% rescue %} for compilation errors. Fallbacks are the only use case for the checks that we've been discussing, and rescue naturally fits in. You try one thing, and, if it doesn't compile, you do the fallback.
The only similar tool of this caliber would be an if compiles(arbitrary expression) but it's easy to abuse (same argument as the one against super powered macros), and also doesn't fit into the macro world (needs to access normal code) and doesn't solve anything if it's in the non-macro world.

@oprypin and if in a next version Random::System gets renamed back to SecureRandom (or some other change break compilation), all applications will silently switch to PCG32.
explicit {% if flag? :has_system_random %} IMHO is better.

@konovod, your initial argument sounds compelling but it's an edge case for pre-1.0 and not worth worrying about.

Well, even after 1.0 there could be rare breaking changes. Another case is that some patch can accidentally introduce compile-time error to the first branch, silently switching app to fallback. This can be partially solved if {% rescue %} will work only for compile-time {℅ raise %}s, not just any error, but it is still error-prone.

I'm not even sure that a {% rescue %} would be technically possible in the compiler.

Hello folks,
Sorry for the delay on getting back on this thread, but wanted to take the proper time and provide some notes from my personal experience, which I hope bring some value into the conversation.
@asterite example of fork is a good one, but before jumping directly to it, I would like to present an average workflow with examples, without theorizing things.
I would use C as language of reference and the workflow around local and cross-compilation. Please bear with me since this might be longer than regular comments, apologies for that.

Let's take the simplest program we can think off, a Hello World! one:
#include <stdio.h>

int main(void)
{
    puts("Hello World!");
    return 0;
}

Now, compiling and running this program locally using GCC or clang should be pretty straightforward:
$ gcc hello.c -o hello

$ file hello
hello: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=0099440eb5b5d10a4e7d132b3ccff3b2e7ba7c33, not stripped

$ ./hello
Hello World!

$

With my program working locally, will be great to explore how to get it running on Windows. Thankfully projects like mingw-w64 provides cross-compilers that run on Linux (ie. Ubuntu with apt install mingw-w64).
$ x86_64-w64-mingw32-gcc hello.c -o hello.exe

$ file hello.exe
hello.exe: PE32+ executable (console) x86-64, for MS Windows

I can now transfer this executable to Windows, or using Wine, run it:
$ wine hello.exe
Hello World!

With a basic binary working, let's now attempt to compile another example that uses fork:
#include <stdio.h>
#include <unistd.h>

int main(void)
{
    int i;
    pid_t pid;

    fork();
    pid = getpid();

    for (int i = 0; i < 3; i++)
    {
        printf("This line is from pid %d, value = %d\n", pid, i);
    }

    return 0;
}

Compiling and running on Linux, works as expected:
$ gcc simple-fork.c -o simple-fork

$ file simple-fork
simple-fork: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d0aff50666b468844f04fc996a8bb311fa0089ee, not stripped

$ ./simple-fork
This line is from pid 32371, value = 0
This line is from pid 32371, value = 1
This line is from pid 32371, value = 2
This line is from pid 32372, value = 0
This line is from pid 32372, value = 1
This line is from pid 32372, value = 2

$

With that working, now trying to cross compile this program for Windows:
$ x86_64-w64-mingw32-gcc simple-fork.c -o simple-fork.exe
simple-fork.c: In function ‘main’:
simple-fork.c:9:5: warning: implicit declaration of function ‘fork’ [-Wimplicit-function-declaration]
     fork();
     ^~~~
/tmp/cc3LNxpR.o:simple-fork.c:(.text+0xe): undefined reference to `fork'
collect2: error: ld returned 1 exit status

$

First thing presented back is a warning: implicit declaration of fork, meaning that for that platform, fork is not defined.
Second, is an error from the linker: it cannot find a reference to fork.
While the above might frustrate me as developer, I can acknowledge that not all platforms are made equal.

Above is nothing new, this is something Crystal already does at the lower level, when targeting different variations of UNIX systems (ie. LibC.sysconf(LibC::SC_NPROCESSORS_ONLN) on Linux vs LibC.sysctl on BSD variations).
If I decided to use LibC::SC_NPROCESSORS_ONLN directly on my Linux box, will end receiving the correct response:
$ crystal eval "puts LibC::SC_NPROCESSORS_ONLN"
84

But another developer on a BSD system will receive an error instead:
$ crystal eval "puts LibC::SC_NPROCESSORS_ONLN"
Error in line 1: undefined constant LibC::SC_NPROCESSORS_ONLN

The coolest part, this already works:
$ cat test-bsd.cr
puts LibC::SC_NPROCESSORS_ONLN

$ crystal build --cross-compile --target amd64-unknown-openbsd test-bsd.cr
Error in test-bsd.cr:1: undefined constant LibC::SC_NPROCESSORS_ONLN

puts LibC::SC_NPROCESSORS_ONLN
     ^~~~~~~~~~~~~~~~~~~~~~~~~

You can say this is the basic of works on my machine example :grin:

Crystal is an application level programming language, as such, it already presents certain abstractions to the lower level details of your OS (like shown above) and I personally believe it should continue doing so.
As a shard author, I might want to interface with certain library or system-level component that might not be available in another platform. The language shouldn't prevent me doing that but, following the same approach, it might error when attempting to compile in another configuration.
Nothing should prevent me from creating a shard that will only work on Linux/BSD, OSX or Windows, or that will only work with certain version of an esoteric third party library.
At a lower level, Crystal already does this internally with LLVM and their different versions.
Now, back to fork example, I see it as two valid questions:
How to know if fork is available?
Julien's suggestion seems excellent. We already have something for instances (Obj.has_method?) but not for class level or lib functions.
As developer doing cross-platform work, I should receive feedback from my build process as early as possible, to help me design and architect the proper solution.
Delay failure until runtime defeats all the benefits of hints (and errors) during build process, which might increase the level of effort and alienate the same developers the language was trying to help.
Some developers might give up supporting platforms as these require more time from them, dealing with testing, VMs, CI and other details.
Should platform-specific code live within Crystal?
Perhaps, or perhaps not. Different languages approach this problem differently.

Rust exposes fork as part of libc package, but only on UNIX platforms 13.
Both Python and Ruby exposes it as interface and raises error on non-UNIX platforms 4 (worth mention Ruby improved that in recent versions).
Go makes it part of the syscall package, but it's usage is completely discouraged 6.

Whatever Crystal team decides, guarding platform specific code and providing proper documentation should be an integral part of that.

If you reached this point, thank you for patience reading this and looking forward your feedback and comments.
Please take all the above as my personal opinion and in no way as the one and only way of doing things.
Cheers.

Crystal follows Go way to use coroutines. So fork should be far away from recommended practices somewhere in deephole/syscall.

#codetriage The bigger consensus here seems to be that we should strive for compile time errors, even if that means pushing more platform handling code to the developer. We should gather experience with this as we add support for more diverse platforms and eventually support developers with compile time functionality for handling platform differences where the standard library cannot hide them. Discussions about specific ideas for such functionality belong to their own individual issues.
I think we can close this for now.


Implement querying for fulltext matches.

This is just one possible approach.  It would be possible to always
produce a computed table, which might be simpler: there would be no
new column types, and there wouldn't be the awkward VALUES table for
?score.  On the other hand, this approach follows the
Clojure{Script} implementation, and, if ?score is not bound, is
likely to be queried more efficiently by SQLite.

@rnewman this is ready for review.  The PR is odd since it's against my own repo.  After you review the underlying work on ground and we land a version of that, I can make this PR against mozilla/mentat.

This landed long ago.


Add editor assignments, permission scheme, and substantive changes

This pull request aims to address the concerns raised across the issues and pull requests itemized below. Of particular note, it merges the branches in pulls #82 and #78, and discards #81, which was no longer necessary.
The changes proposed are the result of collaboration with many of the people involved in the issues and pulls listed. Most importantly, the issues have been discussed with @timbl directly, and the proposed approach related to editor assignments and the editorial team is his recommended solution.

#57 - Definition of substantive changes in the editorial process might cause trouble
#36 - Current editor PRs do not provide sufficient details for an informed decision
#74 - Process Changes
#82 - Pull Request - Make definition of substantive changes more specific
#81 - Pull Request - Add areas of focus to editors.md
#78 - Pull Request - Detail Solid GitHub permissions associated to roles

👍

👍

What would be great to include as well is:

the aim/ scope of the specification
the aim/ scope of the roadmap
the aim/ scope of the documentation
the respective repositories to which proposals in the form of pull requests to the specification, roadmap, and documentation should be made
the aim of each repo and how it connects to this process

What would be great to include as well is:

the aim/ scope of the specification
the aim/ scope of the roadmap
the aim/ scope of the documentation
the respective repositories to which proposals in the form of pull requests to the specification, roadmap, and documentation should be made
the aim of each repo and how it connects to this process

@Mitzi-Laszlo Agree there's value in providing more context around these. Have created a new issue that we can use to track them: solid/process#104

Who will be responsible for moderating the implementation of this process?

The community. It’s self-governing.

Thank you @justinwb for getting this through 🙏


Unique OpenShift vxlan port for KubeVirt Platform

This solves an issue we've been seeing in our e2e tests where the KubeVirt platform's console ingress occasionally fails.
Nested OpenShiftSDN requires unique vxlan ports for the nested layers or else connectivity breaks at the nested layer. This impacts the KubeVirt Hypershift platform because the KubeVirt VMs are running in OpenShiftSDN in the management cluster, and there's another layer of OpenShiftSDN running within the KubeVirt VM worker nodes themselves.
To work around this, when the KubeVirt platform is in use and the OpenShiftSDN network type is being used, we set a unique vxlan port that's different than the default 4789. I picked 9879 for the nested vxlan because it's an unregistered port in the IANA user range. In the future we can consider making this port configurable if we want, but I'm not sure it's worth adding that tuning until we're sure we need it.
Once we transition to OVNKubernetes for the tenant clusters, we'll have a similar issue for the genevePort where we'll need to set a unique genevePort that differs from the one that the management cluster uses.

@davidvossel do we ever anticipate that hypershift would run nested in a hyperhsift kubevirt cluster?

@davidvossel do we ever anticipate that hypershift would run nested in a hyperhsift kubevirt cluster?

Possibly, but not in the near future.
The reasoning is that we don't currently support nested virtualization, at least for OpenShift Virtualization. KubeVirt is technically capable of it (we even use it in testing), but it's not a Red Hat supported configuration. Eventually we're going to sort out a way to make hypershift kubevirt clusters capable of launching VMs, but it's unclear exactly what that will look like right now.

Ack, yup I wasn't thinking of nesting VM's but rather using the root cluster to provision child cluster VM's.
But yeah, if it's something for later, then it can be addressed later
/approve
/lgtm

/hold
I just want to see the kubevirt e2e tests pass before this get's automatically merged. Since kubevirt is still being stabilized, it still isn't required (it will be soon)

/hold cancel
INFO[2022-03-25T20:08:45Z] Step e2e-kubevirt-gcp-kv-e2e succeeded after 23m30s.
INFO[2022-03-25T20:08:45Z] Step phase test succeeded after 29m0s


initial package version fetch, debian and ubuntu, version and name only

Add package version check for packages installed by package manager on a distro. Caches results and has option to force an update and not use the cached version.

Blocking, working on some changes still

Had to remove a type problem, re.Match doesn't need a type subscript 🤦

Typing has a Match class I was supposed to use for re.Match. It looks like it will be deprecated at some point but we can swap to the re.Match class whenever the builds start failing.

@mcgov I think you need implement this method for every distro, when I use SUSE, and invoke this method, it threw NotImplementedError

@mcgov I think you need implement this method for every distro, when I use SUSE, and invoke this method, it threw NotImplementedError

Both of you can help implementing it, if your test cases met it. If the test cases are failed in lab due to lack of implementation, the test case owner should fix it. Thank you.


An option to change numeric inline citations from "Reference 1" to  "ref. 1"?

Pleas see https://github.com/citation-style-language/styles/issues/1535
Thanks!

I think we'll leave this as it is.  Ideally CSL would provide stylistic control over author-in-text citations, but until they do, I want to keep this as simple as possible, and not start creating our own new system for styling these.

See also #133


Usage in embedded scenario (Wordpress Plugin Application)

I'm using this in an embedded scenario inside of our video editor wordpress plugin.
The wordpress css is leaking in and adding borders around the hidden file input. So i added:
.x-file--input {
    width: 1px;
    padding: 0 !important;
    margin: 0 !important;
}

Maybe you could apply this in your styles to have this "worry free developer"-experience ;)

Hm, adding !importants worries me. The goal for this addon is to make it easier to style file inputs and I don't want to assume that there will never be padding or margin ever added.
We also don't touch the padding & margin in the original CSS.
The more I think about it, the more I think this should be handled in the host application since it's your apps CSS that's leaking.

Hey Rob!
the reason is:  is very common.
So they restyle it everywhere (in wordpress admin panel, facebook, bourbon etc.). Everything that can embed my ember application.
I would normally not add !important somewhere. But whats wrong with !important on something not visible anyways just to make sure it stays invisible and out of the way?
Kind of special situation

Question: Is the <input> element visible in blockless form?

The problem is:
emberx-file-input assumes that the input[type=file] has margin 0, padding 0
But that is not always the case
A lot of dependencies (Bourbon.io, Bootstrap, ...) define something like this:
// Default style for input
input {
margin-bottom:20px;
padding: 5px;
}
Then you see space (5px or 20px) where no space should be.
This space is caused by itself!
Has nothing at all to do with the label! So yes, both forms!


Should the body of an async* method start synchronously on the call to .listen?

The body of an async* method currently starts in a microtask following the call to .listen on the returned stream. This differs from calling .listen on the stream returned by a StreamController where the onListen callback is executed synchronously. I had hoped that the following two approaches to define this method would behave idendically:
import 'dart:async';

Stream<int> justOne() {
  final c = StreamController<int>();
  c.onListen = () {
    print('On listen');
    c.add(1);
  };
  return c.stream;
}

vs
Stream<int> justOne() async* {
  print('On listen');
  yield 1;
}

However they differ. Comparing the output of
void main() async {
  justOne().listen(print);
  print('Listened');
}

The former produces
On listen
Listened
1

While the latter produces
Listened
On listen
1

@lrhn - do you think this would be difficult to change? Do you anticipate it will be very breaking?

Should it be synchronous: Yes!
Difficult to change: Yes. (Don't know how difficult, but it was a large task for @floitschG to make async functions start synchronously. The sync* functions are less common, and probably less timing bound because they often start out listening to other async code, but it won't be trivial. The current behavior is likely baked into the backend implementations).
Very breaking: Possibly, not certainly. The risk is that a few highly used functions depend on timing, not that the majority of code does so independently. If some core part of Flutter event propagation breaks, it's very breaking even if it only really breaks one function. It's really impossible to say without trying.

Closing in favor of https://github.com/dart-lang/sdk/issues/33818


Toaster Event Issue

How to customize the 'toast' event emitted in angular2materialize.

Have you tried importing directly from materializecss?
import { toast } from 'materialize-css';

Then use it by saying
toast('I am a funny toast! ', 4500);


ROU-3183: Fix Issue when copy & paste a row that have child cells

This PR is for remove OnCellValueChange async trigger and set it definitely sync.
Since we had an IF checking if the action that trigger the OnCellValueChange was performed by a Filter it was synchrony triggered and changing it to be definitely synchrony triggered it will solve the Issue when copy & paste a row that have child cells (Parent Binding)

Please don't merge this yet, as we need #218 first, since we fixed an issue with azure.


store commands?

I think there is a lot of value in storing each incoming command as well, not just the resulting events. Do you agree? Would that be outside the scope of the library?

this library uses event sourcing... so only storing events (these are the facts)
but if you need to store the commands just do it before handling them in cqrs-domain...
May I ask why you need to store them?

I think (being a CQRS/ES-newbie) it can be useful for:

tracking the original trigger for one or multiple events, including meta data about the request (e.g. user agent) - leading to better debugging/auditing capabilities in production
being able to match an AJAX request with exactly one entity, the command - then one could easily reference the status of the command (e.g. if it was rejected: one could easily query for it and learn about that it was not valid, since there aren't any events in that case)
'time travelling' (maybe?): in development, the client could display a number of successful commands and - on click - revert them
retry mechanism: In addition, you can persist the Command messages to a store and easily support Re-playable Operations to handle retry logic or system restores (from CQRS Journey)

Maybe I'm wrong and all this can be achieved through events already. I'm very interested in what your experience taught you here :)

I recommend to do this outside of cqrs-domain...
Just one more advice: think about scalability&concurrency ;-)

Thanks, just wanted to see your opinion :)


Provide an 'EpochInfo' that can fail to ledger.

The ledger now supports an EpochInfo (Either Text), and uses the
Left constructor to indicate a horizon error. Unfortunately, while the
epoch info being provided had the correct type, it was implemented in
a degenerate way - the Left constructor would never be used and
instead a pure error was thrown on failures.
This PR instead provides a correct EpochInfo to the ledger, where the
failure is reflected in the Left constructor.

I did go through the other uses of toPureEpochInfo and think they are all legit. We otherwise use it only for epoch/slot computations for the current slot.

bors merge

I did go through the other uses of toPureEpochInfo and think they are all legit. We otherwise use it only for epoch/slot computations for the current slot.

I see a few remaining uses of toPureEpochInfo.

tickChainDepState @Praos passes it to isNewEpoch to check whether we're ticking past an epoch boundary. It converts the slot we're ticking to an epoch (which could fail) and compares epochs -- I think it should instead convert the end of the current epoch to a slot (which can't fail) and then compare slots

checkIsLeader @TPraos uses it to compute the firstSlot (of the epoch) of the given slot when calling SL.lookupInOverlaySchedule firstSlot .... As in the previous case, that translation can also fail, but I don't see an alternative that can't fail.

tickChainDepState @TPraos uses it as does tickChainDepState @Praos above

So I think we should fixup the tickChainDepState calls to use unfailing translations instead of failing translations.

bors retry


Can't run docs/source/notebooks/glayout/GLayout_Cells.ipynb

The Run in Colab link points to a different file.
glayout is not loaded as a module, which causes an error in 1.3. Importing Libraries and Utility Functions

ModuleNotFoundError                       Traceback (most recent call last)
[<ipython-input-31-fc1af012fbf9>](https://localhost:8080/#) in <cell line: 1>()
----> 1 from glayout.pdk.sky130_mapped import sky130_mapped_pdk as sky130
      2 from glayout.pdk.gf180_mapped  import gf180_mapped_pdk  as gf180
      3 import gdstk
      4 import svgutils.transform as sg
      5 import IPython.display

ModuleNotFoundError: No module named 'glayout.pdk.sky130_mapped'

Creating link to glayout in step 1.1 as below, loads the module.

!ln -s OpenFASOC/openfasoc/generators/gdsfactory-gen/glayout .

This results in a different error sky130_mapped_pdk.cell_decorator_settings.cache=False where cell_decorator_settings does not have the cache object.

ValueError                                Traceback (most recent call last)
[<ipython-input-34-fc1af012fbf9>](https://localhost:8080/#) in <cell line: 1>()
----> 1 from glayout.pdk.sky130_mapped import sky130_mapped_pdk as sky130
      2 from glayout.pdk.gf180_mapped  import gf180_mapped_pdk  as gf180
      3 import gdstk
      4 import svgutils.transform as sg
      5 import IPython.display

2 frames
[/content/glayout/pdk/sky130_mapped/__init__.py](https://localhost:8080/#) in <module>
      3 """
      4
----> 5 from glayout.pdk.sky130_mapped.sky130_mapped import sky130_mapped_pdk

[/content/glayout/pdk/sky130_mapped/sky130_mapped.py](https://localhost:8080/#) in <module>
     50 # set the grid size
     51 sky130_mapped_pdk.gds_write_settings.precision = 5*10**-9
---> 52 sky130_mapped_pdk.cell_decorator_settings.cache=False
     53 sky130_mapped_pdk.gds_write_settings.flatten_invalid_refs=False

[/usr/local/lib/python3.10/dist-packages/pydantic/main.py](https://localhost:8080/#) in __setattr__(self, name, value)
    793         elif self.model_config.get('extra') != 'allow' and name not in self.model_fields:
    794             # TODO - matching error
--> 795             raise ValueError(f'"{self.__class__.__name__}" object has no field "{name}"')
    796         elif self.model_config.get('extra') == 'allow' and name not in self.model_fields:
    797             if self.model_extra and name in self.model_extra:

ValueError: "CellDecoratorSettings" object has no field "cache"

This may be due to the removal of the assignment in openfasoc/generators/gdsfactory-gen/glayout/pdk/mappedpdk.py
    def from_gf_pdk(
        cls,
        gfpdk: Pdk,
        **kwargs
    ):
...
#        passargs["cell_decorator_settings"]=gfpdk.cell_decorator_settings

Removing the line causing the error, results in other errors. Maybe there's an older version that works?
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
[<ipython-input-44-fc1af012fbf9>](https://localhost:8080/#) in <cell line: 1>()
----> 1 from glayout.pdk.sky130_mapped import sky130_mapped_pdk as sky130
      2 from glayout.pdk.gf180_mapped  import gf180_mapped_pdk  as gf180
      3 import gdstk
      4 import svgutils.transform as sg
      5 import IPython.display

2 frames
[/content/glayout/pdk/sky130_mapped/__init__.py](https://localhost:8080/#) in <module>
      3 """
      4
----> 5 from glayout.pdk.sky130_mapped.sky130_mapped import sky130_mapped_pdk

[/content/glayout/pdk/sky130_mapped/sky130_mapped.py](https://localhost:8080/#) in <module>
     51 sky130_mapped_pdk.gds_write_settings.precision = 5*10**-9
     52 #sky130_mapped_pdk.cell_decorator_settings.cache=False
---> 53 sky130_mapped_pdk.gds_write_settings.flatten_invalid_refs=False

[/usr/local/lib/python3.10/dist-packages/pydantic/main.py](https://localhost:8080/#) in __setattr__(self, name, value)
    793         elif self.model_config.get('extra') != 'allow' and name not in self.model_fields:
    794             # TODO - matching error
--> 795             raise ValueError(f'"{self.__class__.__name__}" object has no field "{name}"')
    796         elif self.model_config.get('extra') == 'allow' and name not in self.model_fields:
    797             if self.model_extra and name in self.model_extra:

ValueError: "GdsWriteSettings" object has no field "flatten_invalid_refs"

Ok. So during the first installation, there was this message
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
gf180 0.1.0 requires gdsfactory<7.17,>=7.16.0, but you have gdsfactory 7.7.0 which is incompatible.
sky130 0.10.1 requires gdsfactory==7.16.0, but you have gdsfactory 7.7.0 which is incompatible.

So I bumped the gdsfactory version to 7.16.0 which seems to have broken everything.

glayout is not loaded as a module, which causes an error in

This is probably because the installation steps seem to be missing a cd step. I'll make PR fixing this soon.
Until then, can you try using the installation steps in the first cell of this notebook?
cc: @andylithia


can not build on ros2 humble

Summary: 74 packages finished [31.6s]
6 packages had stderr output: controller_manager moveit_configs_utils ros2_controllers_test_nodes ros2controlcli rqt_controller_manager rqt_joint_trajectory_controller
ex:
stderr: ros2controlcli
/usr/lib/python3/dist-packages/setuptools/command/easy_install.py:158: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools.

ros2 launch ur_simulation_gazebo ur_sim_moveit.launch.py
[INFO] [launch]: All log files can be found below /home/devtex/.ros/log/2024-03-14-18-39-08-463600-devtex-HP-Z1-281710
[INFO] [launch]: Default logging verbosity is set to INFO
[ERROR] [launch]: Caught exception in launch (see debug for traceback): executed command failed. Command: /opt/ros/humble/bin/xacro /home/devtex/workspaces/ur_gazebo/install/ur_simulation_gazebo/share/ur_simulation_gazebo/urdf/ur_gazebo.urdf.xacro safety_limits:=true safety_pos_margin:=0.15 safety_k_position:=20 name:=ur ur_type:=ur5e prefix:="" simulation_controllers:=/home/devtex/workspaces/ur_gazebo/install/ur_simulation_gazebo/share/ur_simulation_gazebo/config/ur_controllers.yaml
Captured stderr output: error: No such file or directory: /home/devtex/workspaces/ur_gazebo/install/ur_description/share/ur_description/urdf/inc/ur_joint_control.xacro [Errno 2] No such file or directory: '/home/devtex/workspaces/ur_gazebo/install/ur_description/share/ur_description/urdf/inc/ur_joint_control.xacro'
when processing file: /home/devtex/workspaces/ur_gazebo/install/ur_simulation_gazebo/share/ur_simulation_gazebo/urdf/ur_gazebo.ros2_control.xacro
included from: /home/devtex/workspaces/ur_gazebo/install/ur_simulation_gazebo/share/ur_simulation_gazebo/urdf/ur_gazebo.urdf.xacro

Hey @T-BonesLek, I had problems building on humble too.  Here's what they left out of the documentation that makes it impossible to build in humble if you're just following the documentation:
First of all, the ros2 branch is just the ros2 rolling branch.. there are separate branches for iron and humble.  So for humble you would git clone with this command in your src folder:
git clone git@github.com:UniversalRobots/Universal_Robots_ROS2_Gazebo_Simulation.git -b humble
Secondly, the repos file for each individual ros2 branch i.e. Universal_Robots_ROS2_Gazebo_Simulation.<ros-distro>.repos downloads repositories from source which is unnecessary.  There should only be one folder in your src  folder and that is ur_simulation_gazebo.  The rest can be downloaded with apt so if you didn't have them already (you probably have a few) that command would be:
sudo apt install ros-humble-ur* ros-humble-gazebo-ros2-control ros-humble-moveit* ros-humble-ros2-control ros-humble-ros2-controllers
The asterisk next to packages means download every package that begins with that name just so you don't miss any.  That command replaces the vcs whatever and rosdep blah blah blah commands because they would just use the original repo file, Universal_Robots_ROS2_Gazebo_Simulation.humble.repos, so that they don't get downloaded into your src folder and built with colcon.
Lastly, they say to use colcon build --symlink-install --mixin rel-with-deb-info compile-commands ccache to build, but I'm pretty sure you don't need all those extra arguments on there..  I would try just building with a plain old colcon build but if you want the whole enchilada, here's how you add all that on there (assuming you have colcon from sudo apt install ros-dev-tools):

Download mixin with sudo apt install python3-colcon-mixin
Register the repository with colcon mixin add default https://raw.githubusercontent.com/colcon/colcon-mixin-repository/master/index.yaml
Fetch the latest from said repo with colcon mixin update default
Install ccache with sudo apt install ccache
Update symlinks with sudo /usr/sbin/update-ccache-symlinks
Prepend ccache into $PATH with echo 'export PATH="/usr/lib/ccache:$PATH"' | tee -a ~/.bashrc
Source bashrc to run a lil test to make sure everything went okay with source ~/.bashrc && echo $PATH

The output should have "/usr/lib/ccache..." at the front of it, and you should be set to go!  Probably went into more detail than I had to, but all that detail was lacking in the documentation soooo it is what it is.  Let me know how that goes if you're still trying to build with humble.

It's functioning flawlessly following your instructions! I'm hopeful that extending it for my project will be straightforward. Your assistance is greatly valued @liamcarlos !

@T-BonesLek Awesome!  Glad I helped!


Report cell temperatures correctly for SeplosV2

fixes #1072

Yes, please make a PR for this in my repository.

https://github.com/Louisvdw/dbus-serialbattery/issues/1072#issuecomment-2143994392
Thanks


Migrate to v10

Passing along some info I read in the #dnd5e channel of Foundry's Discord. The new vision/detection modes has some interaction with the status effects. For example, marking a token as invisible hides them but if a token has the detection mode to see invisible then it'll show that token to them. Since this module replaces the status effects, that won't work because it's using status effect IDs to tell that a token is invisible.
You'll want to update CONFIG.specialStatusEffects to match your status effect IDs if you're replacing the existing status effects. I don't know what to do if you're just adding to the existing ones, since you can't have two status IDs for invisible.

This is actually already in the code, but I appreciate you reaching out to make sure!


wip: invoke e2e tests

This is just a test to invoke the new pull-cip-auditor-e2e test (it
should pass --- if it doesn't GCP permissions are messed up somewhere).
/hold

/test pull-cip-auditor-e2e

/test pull-cip-auditor-e2e

/test pull-cip-auditor-e2e

/uncc @dims @tpepper

/unassign @dims @tpepper

/test pull-cip-auditor-e2e

/test pull-cip-auditor-e2e

/test pull-cip-auditor-e2e

/test pull-cip-auditor-e2e

/test pull-cip-auditor-e2e

/test pull-cip-auditor-e2e

The pull-cip-auditor-e2e test is now passing!
For the record, I had to do 2 things manually because I felt that putting them in the auditor test code was not the best thing:
(1) create a Pub/Sub topic named gcr (this is used by GCR's Pub/Sub integration)
(2) make the "gcr.io" registry host Public instead of Private (for some reason, {asia,eu,us}.gcr.io/k8s-gcr-audit-test-prod all had Public visibility but just gcr.io/k8s-gcr-audit-test-prod was Private, leading to errors when the promoter was trying to read from it).
We would need to do the above things in the k8s-artifacts-prod project before launching the cip-auditor to Cloud Run.
/cc @thockin @justinsb @dims
/hold

/cc @cblecker

/approve

/lgtm

@bartsmykla FYI I created https://github.com/kubernetes-sigs/k8s-container-image-promoter/pull/174 to add you to OWNERS.


Field lifecycle methods

The field methods like fset etc. are getting more and more complicated, so complicated that it is basically crazy to override them. For example, I've added fvalue and ivalue to normalize the values as they are set into the orm and the db, so I can lowercase the value without overriding the current fset, iset, or similar methods.
The question is should I make it so you can still override the methods but not override the main calling methods? Basically, make fvalue be fset and ivalue be iset and then have external methods that do all the current things but then call all the defined iset things.
I'll have to think about the best way to implement this.

I think I should keep all the decorator names the same, but have them set _<METHOD-NAME> that will then get called by the corresponding method if they exist, so:

foo = Field(int)

# this will set fooset into foo._iset
@foo.isetter
def fooset(self, value):
    return value + 1

# foo._iset will get called at the end of foo.iset

So I would modify Field.iset to look something like this:
def iset(self, orm, value):
    # all the normal iset stuff
    if self._iset:
        value = self._iset(orm, value)
    return value

This way I can keep basically the same interface, keep the ever increasing amount of logic in all the lifecycle methods, and still allow easy customization


the generation results contain some null samples

System Info
torch==2.1.2
transformers==4.31.0.dev0
bitsandbytes==0.39.1
peft==0.5.0
accelerate==0.25.0
datasets==2.15.0
Who can help?
No response
Information

[ ] The official example scripts
[ ] My own modified scripts

Tasks

[ ] An officially supported task in the examples folder
[ ] My own task or dataset (give details below)

Reproduction
def generate_prompt(source, target=None, eos_token="</s>", ):
    input = f"{source}\n"
    if args.transfer == "infor2form":
        instruction = "Rewrite the following sentence, maintain the content and change the style from informality to formality:\n"
        output = f"Rewrite: {target + ' ' + eos_token if target else ''} "
    prompt = (" ").join([instruction, input, output])
    return prompt

def formatting_func(prompt):
    output = []
    for d, s in zip(prompt["source"], prompt["target"]):
        op = generate_prompt(d, s)
        output.append(op)
    return output

quant_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True
)

lora_config = LoraConfig(
        r=16,
        lora_alpha=8,
        lora_dropout=0.05,
        target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],
        bias="none",
        task_type="CAUSAL_LM",
    )

Expected behavior
I finetune Llama-2 with LORA bf16, after the  finetuning process, I load the checkpoint and do the test with 500 samples, but get almost 30 samples reply nothing or '\n'. Do you have any ideas how to fix it?

Honestly these types of issues are super hard to debug. It doesn't sound like a LoRA issue per se, maybe the model was not trained well enough or some training samples are empty for some reason? Are these 30 empty generations always for the same samples or random? Can you get a result when you try the same prompt multiple times?