text:
Implement unit-tests for UpdateNuGetConfigPackageSourcesMappings task

Source-build tasks do not have any unit-tests. As tasks get complex tests are even more important, as was experienced with this task. There were developer-centric tests, which need to be converted into unit-tests.
This is related to https://github.com/dotnet/source-build/issues/4666
As part of this work, it is important to improve organization of unified build and source-build tests. Currently we have two projects in VMR, under test, both of them are product tests. Source-build tests should run both source-build and unified-build tests, as those are common - today. In the future there will likely be some tests that are specific to unified build and not applicable to source-build. Common, source-build and unified-build (or Microsoft) tests are 3 natural classes of tests. Perhaps unified-build tests can be marked appropriately, so that common tests are included in source-build testing.
Unit-tests are usually built and run as part of the same build so they consume the same dependencies. Product tests are intentionally removed from main build, to enable these test projects to consume artifacts (including packages) that are produced by unified- (or source-) build.
Open question: should unit-tests for unified-build and source-build tasks be built/executed together with product tests or earlier in the build when tasks are built.

@MichaelSimons @ViktorHofer

Open question: should unit-tests for unified-build and source-build tasks be built/executed together with product tests or earlier in the build when tasks are built.

IMO the current sequence point (the Test target) is appropriate and I wouldn't change that. Our repo official builds usually don't run tests (there are a few outliers, i.e. vstest). We decided on that few years back for improved reliability and build times.
If we need a place to do unit testing then I would recommend adding a new test project under /test.

As part of this work, it is important to improve organization of unified build and source-build tests. Currently we have two projects in VMR, under test, both of them are product tests. Source-build tests should run both source-build and unified-build tests, as those are common - today. In the future there will likely be some tests that are specific to unified build and not applicable to source-build. Common, source-build and unified-build (or Microsoft) tests are 3 natural classes of tests. Perhaps unified-build tests can be marked appropriately, so that common tests are included in source-build testing.

Sounds good.

Currently we have two projects in VMR, under test, both of them are product tests. Source-build tests should run both source-build and unified-build tests, as those are common - today.

The current source-build tests are a mixture of unit tests and scenario tests.  https://github.com/dotnet/source-build/issues/4384 tracks removing the scenario tests now that we have a shared set of tests in the scenarios-tests repo.
Source-build does not and should not run the current unified-build tests.  The current unified build tests are transient only for the purposes of comparing the unified build leg output to the current Microsoft builds as a means to identify differences in the unified build.

Common, source-build and unified-build (or Microsoft) tests are 3 natural classes of tests.

I like the idea of three separate projects for this.

However, I believe a better option might be to build unit-tests project along with tasks project, at the same time, using the same dependencies. That way we'd be building the tests using the same toolset and dependencies. Tasks are used during build, and consume old dependencies, unit-tests should consume those same dependencies. This allows unit-tests to test the actual tasks experience. In this scenario, we'd need to ensure we have the dependencies available during testing.

I don't think that's the right approach. We want to build the unit test projects independently and also not part of the main build. That's why we have tests.proj as a separate unit.

remaining question is about unit-test location

IMO the location should be a separate project under test/.

It should be possible to introduce some new '.proj` file to build the tasks project again, during testing to publish to a different location, and have it consume new dependencies.

We want to test the tasks that are executed as part of the VMR build, hence they shouldn't get rebuilt with a different set of inputs.

Anything under test is build using artifacts produced by build.

Would you mind elaborating on that? How is that enforced today?

I might have phrased some of my previous comments tersely. When we build tests we have all the newly produced packages in NuGet store, which can lead to issues with package mismatch.
However, the issue I have seen in my initial attempt to add unit-tests is somewhat different.
Test project directly depends on NuGet.Protocol (and indirectly other NuGet.* packages) version 6.9.1 - getting dependency from root Directory.Packages.props, and version from eng/Versions.props - https://github.com/dotnet/sdk/blob/8584c262d4d2e1a0af388271ae0715db3c53a2b6/src/SourceBuild/content/test/Microsoft.DotNet.UnifiedBuild.Tests/Microsoft.DotNet.UnifiedBuild.Tests.csproj#L13
When I added the unit-test source file to this project and a necessary reference to Tasks project, I got the following build errors (just one here, for brevity):
/src/git/dotnet/.dotnet/sdk/9.0.100-rc.1.24452.12/Microsoft.Common.CurrentVersion.targets(2413,5): error MSB3277: Found conflicts between different versions of "NuGet.Packaging" that could not be resolved.
There was a conflict between "NuGet.Packaging, Version=6.9.1.3, Culture=neutral, PublicKeyToken=31bf3856ad364e35" and "NuGet.Packaging, Version=6.12.0.81, Culture=neutral, PublicKeyToken=31bf3856ad364e35".
    "NuGet.Packaging, Version=6.9.1.3, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was chosen because it was primary and "NuGet.Packaging, Version=6.12.0.81, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was not.
    References which depend on "NuGet.Packaging, Version=6.9.1.3, Culture=neutral, PublicKeyToken=31bf3856ad364e35" [/src/git/dotnet/.packages/nuget.packaging/6.9.1/lib/net5.0/NuGet.Packaging.dll].
        /src/git/dotnet/.packages/nuget.packaging/6.9.1/lib/net5.0/NuGet.Packaging.dll
          Project file item includes which caused reference "/src/git/dotnet/.packages/nuget.packaging/6.9.1/lib/net5.0/NuGet.Packaging.dll".
            /src/git/dotnet/.packages/nuget.packaging/6.9.1/lib/net5.0/NuGet.Packaging.dll
    References which depend on or have been unified to "NuGet.Packaging, Version=6.12.0.81, Culture=neutral, PublicKeyToken=31bf3856ad364e35" [].
        /src/git/dotnet/artifacts/bin/Microsoft.DotNet.UnifiedBuild.Tasks/Release/Microsoft.DotNet.UnifiedBuild.Tasks.dll
          Project file item includes which caused reference "/src/git/dotnet/artifacts/bin/Microsoft.DotNet.UnifiedBuild.Tasks/Release/Microsoft.DotNet.UnifiedBuild.Tasks.dll".
            /src/git/dotnet/artifacts/bin/Microsoft.DotNet.UnifiedBuild.Tasks/Release/Microsoft.DotNet.UnifiedBuild.Tasks.dll [/src/git/dotnet/test/Microsoft.DotNet.UnifiedBuild.Tests/Microsoft.DotNet.UnifiedBuild.Tests.csproj]

This was caused by direct references to NuGet assemblies in .NET SDK, from the Tasks project, and other projects under tools: https://github.com/dotnet/sdk/blob/8584c262d4d2e1a0af388271ae0715db3c53a2b6/src/SourceBuild/content/eng/tools/Directory.Build.props#L9-L19
  <!--
    Use some assemblies from the SDK, instead of package references. This ensures they match what's
    found when the task is loaded by the SDK's MSBuild.
    Reference NuGet assemblies, except a command line assembly that causes warnings such as:
    MSB3277: Found conflicts between different versions of "System.Collections" that could not be resolved.
  -->
  <ItemGroup>
    <SdkAssembly Include="$([MSBuild]::NormalizePath('$(NetCoreRoot)', 'sdk', '$(NETCoreSdkVersion)', 'Newtonsoft.Json.dll'));
                          $([MSBuild]::NormalizeDirectory('$(NetCoreRoot)', 'sdk', '$(NETCoreSdkVersion)'))NuGet.*.dll"
                 Exclude="$([MSBuild]::NormalizePath('$(NetCoreRoot)', 'sdk', '$(NETCoreSdkVersion)', 'NuGet.CommandLine.XPlat.dll'))" />
  </ItemGroup>

While, I can solve this by creating a new project for unit-tests, that would not have a dependency on any NuGet.* packages (as I don't need them), there might be other unit-tests in the future, that would need NuGet.* packages and will hit this issue. So, I think that we should have the right solution in place, to avoid such issues down the road.

Yes, that makes sense. It's a mismatch between a direct assembly reference (the NuGet assemblies from the .NET SDK) and a package reference. That is a general problem and RAR (ResolveAssemblyReference) warns about these to make sure that dependencies are compatible and can be unified.
Here, either all tasks need to use a package reference or if that isn't possible (i.e. because of prebuilts), the projects that reference task projects need to use the same mechanism to reference NuGet assemblies. Note that this only affects NuGet assemblies and Newtonsoft.Json. We have a tracking issue to remove the latter eventually.
Hope that helps.

repo: dotnet/source-build


text:
'OmniSharp: Select Project' resulted in an error

We have written the needed data into your clipboard because it was too large to send. Please paste.

I was told in a previous issue that this is fixed in a prerelease:
https://github.com/OmniSharp/omnisharp-vscode/releases/tag/v1.23.18-beta2

how do i use the pre-release? it doesn't seem to be published in a way that i can easily select that version

https://github.com/OmniSharp/omnisharp-vscode/wiki/Installing-Beta-Releases

can someone on the omnisharp team please release the fix, or at least rollback breaking changes... ?, my omnisharp has been broken for days now :(

team please release the fix, or at least rollback breaking changes...

@jannickj Sorry, the changes in the new VS Code release conflicted with our existing behavior. Please try installing one of our prerelease builds (https://github.com/OmniSharp/omnisharp-vscode/releases/tag/v1.24.0-beta1) that include a fix. At this point we won't be able to do a proper release until after the winter holidays.

yeah my bad I forgot to update my comment I thought it was a broken release on omnisharp, but it was vscode that made the breaking change.

When I uninstall the extension C# Dev Kit, the problem is fixed. I think that has a conflict with that extension and Omnisharp.

Closing as original issue is resolved.

source: gharchive/issue

authors: JoeRobich PsychoNineSix TomasEkeli gregg-miskelly jannickj tarus622 trungnguyen10

repo: dotnet/vscode-csharp

license: MIT

license_type: permissive

license_source: github-api


text:
Bump .NET SDK to 8.0.402 and install workload-set version 8.0.402.0 from nuget.org

Microsoft Reviewers: Open in CodeFlow

/azp run

source: gharchive/pull-request

repo: dotnet/xcsync


text:
Course ID discrepancy

We get the course ID from the replaces field in the INI while the MKDD Track Patcher and the MKDD Extender rely on the name of the files in course.arc. There are tracks in the wild for which these 2 methods yield different results. During the enumeration, we only need the course ID to know the type of the track (race or battle). Thus, we could keep using the INI value here, and get the actual course ID based on course.arc once the track is loaded.

My previous analysis turns out to be incorrect: with the Extender, the course ID is actually based on track ordering. Both the Patcher and the Extender patch the minimap Race2DParam calls which I misinterpreted as a course ID change. Thus there isn't really a reason to change the way course IDs are handled (the code can maybe be shortened a bit). However, Race2DParam calls will need to be adjusted.

repo: doubledashdeluxe/ddd


text:
🛑 VNUX.dev is down

In f77a6aa, VNUX.dev (https://vnux.dev) was down:

HTTP code: 0
Response time: 0 ms

Resolved: VNUX.dev is back up in df397d3.

repo: dougdragon/uptime


text:
Build warning: "strippedNativeLibsDir is deprecated and no longer used"

note: this is neither a bug report nor a feature request, though I'm not terribly familiar with Gradle itself or working with native Android code... I apologise in advance if I've missed something "simple" here.
FWIW, I've been fighting with trying to get an older Ionic Angular app upgraded for a re-release, and I'm working through all the potentially problematic points mentioned from my project's build output logging.

after the resources copy process, when the build runs the "Configure project :app" step, I see the following warning:
strippedNativeLibsDir is deprecated and no longer used. Please remove it from your build configuration.

after a bit of digging, I discovered that cordova-plugin-firebasex@14.0.0 declares com.google.firebase:firebase-crashlytics-gradle:2.8.1 as a buildscript dependency in build.gradle line 10, along with both unstrippedNativeLibsDir and strippedNativeLibsDir on lines 31 and 32 of the same file.
reading through the comments on a seemingly related issue in React Native Firebase, I found one stating that the strippedNativeLibsDir key can be removed.
digging a little deeper, I see entries in the historic Firebase Android changelogs for the "Crashlytics Gradle Plugin" where:

2.4.0: (deprecated) strippedNativeLibsDir defined in the firebaseCrashlytics extension is no longer necessary and will be removed in a future release.
2.5.1: (fixed) Removed unnecessary validation for obsolete strippedNativeLibsDir property.
2.7.0: (changed) The Crashlytics Gradle plugin now prints a warning recommending removal of the strippedNativeLibsDir property, which was formerly required when using the unstrippedNativeLibsDir property. strippedNativeLibsDir is no longer used and should be removed from your build configuration.

going by the age of these releases (and that cordova-plugin-firebasex already uses 2.8.1), surely build.gradle line 32 can just be removed outright and everything will continue to work, not so? unless there's some special reason this is still hanging around today?

How to fix it ?
.-.

i'm not the expert on java.

How to fix it ?

this is just a deprecation warning, so it won't cause your build to fail.. sorry to say, I believe you might have a different issue there.
I would suggest re-running your command with --verbose, and if that doesn't help you solve it, you could open a new issue for that. 🖖🏼

authors: ZaLiTHkA eeerrrttty


text:
🛑 Workstation Service is down

In f69bd29, Workstation Service (https://workstation.dpG06.top) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Workstation Service is back up in 95cd81b after 12 minutes.

repo: dplayz/status


text:
🛑 Fastbin Service is down

In de4bfaf, Fastbin Service (https://paste.dpG06.top) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Fastbin Service is back up in 27c476e after 20 hours, 19 minutes.


text:
Warm up JIT for formatting code on initialization

Whatever file happens to be formatted first will take a LONG time to format (500ms) because of JIT. If a second plugin gets created by the CLI then the next format will take an even longer time.
This means the following events could happen:
0ms 1st plugin starts being created
100ms file1.cs format start [1st plugin]
300ms 2nd plugin starts being created
400ms file2.cs format start [2nd plugin]
600ms file1.cs format finish [1st plugin]
601ms file3.cs format start [1st plugin]
630ms file3.cs format finish [1st plugin]
900ms file2.cs format finish [2nd plugin]
901ms program exists

A more ideal sequence of events would be:
0ms 1st plugin starts being created
300ms 2nd plugin starts being created
500ms 1st plugin created and initialized
501ms file1.cs format start [1st plugin]
530ms file1.cs format finish [1st plugin]
531ms file2.cs format start [1st plugin]
560ms file2.cs format finish [1st plugin]
561ms file3.cs format start [1st plugin]
590ms file3.cs format finish [1st plugin]
591ms program exists

So, as you can see, the thread for the creation of the second plugin is thrown away and never completes. The CLI has the ability to do this already, but this plugin just needs to ensure it's JIT ready before formatting a file.
I understand this is only an issue when there are a small amount of files, but this will most likely be the case because people will generally use "incremental" formatting. This also makes the output of dprint output-format-times meaningful as right now it's just long for whatever files happen to be formatted first.

This blog seems useful: https://www.liranchen.com/2010/08/forcing-jit-compilation-during-runtime.html
I don't believe using ngen works with .net core. It seems that it can be published with "PublishReadyToRun" set to true: https://codetherapist.com/blog/netconf-netcore3-crossgen/ (that will require building on the platforms, which is not a big deal... just use a matrix on the CI)

The "PublishReadyToRun" did basically nothing for startup time.
The "forcing JIT compilation" didn't work in .net core. Got a PlatformNotSupported exception calling RuntimeHelpers.PrepareMethod
Formatting some dummy code first worked, but startup times are still way to slow. In the editor when a file is being saved there's too much of a delay. I think an AOT solution is necessary... looking into CoreRT right now.

CoreRT doesn't seem stable enough at the moment and I haven't found any other solution that works. Not going to do this for now and instead will implement https://github.com/dprint/dprint/issues/284

Explanation on why CoreRT didn't work is here: https://github.com/dotnet/corert/issues/8202#issuecomment-671160593

Roslyn has infinite recursive expansion around Microsoft.CodeAnalysis.VisualBasic.TypeArgumentInference.StronglyConnectedComponent ...

If you see the compiler not making progress and consuming a lot of memory, it is pretty much always infinite generic expansion. We know that we need a better error reporting for it.

repo: dprint/dprint-plugin-roslyn


text:
Add a loopback path instead of localhost

Check for loopback before sending. Used a dispatch map to deal with generic broadcastToReplica. Fixed redundant broadcast of fallbackTrigger.

Another thing, with this change, we can get rid of the ugly (and rather confusing) way which we setup a loopback NNG connection on the replicas. Can you make that part of the PR?
Specifically, it would in getReplicaAddrs of config_util.h and the constructor of Replica.


text:
TypeError: 'in ' requires string as left operand, not NoneType

The latest release has this line  which fills in self.state value if state does not exist in kwargs but it does not help if kwargs['state'] exists but is None. Example repro:
Broken Version 0.12
# pip show holidays
Name: holidays
Version: 0.12
...
# python
Python 3.7.12 (default, Jan  4 2022, 02:07:00)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import holidays
>>> h = holidays.UK(prov=None, state=None, years=[2020], expand=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/apps/python3/lib/python3.7/site-packages/holidays/countries/united_kingdom.py", line 36, in __init__
    HolidayBase.__init__(self, **kwargs)
  File "/apps/python3/lib/python3.7/site-packages/holidays/holiday_base.py", line 182, in __init__
    self._populate(year)
  File "/apps/python3/lib/python3.7/site-packages/holidays/countries/united_kingdom.py", line 109, in _populate
    self._country_specific(year)
  File "/apps/python3/lib/python3.7/site-packages/holidays/countries/united_kingdom.py", line 160, in _country_specific
    if self.state not in ("Scotland") and year >= 1971:
TypeError: 'in <string>' requires string as left operand, not NoneType

Last working Version: 0.11.3.1
# pip show holidays
Name: holidays
Version: 0.11.3.1
...
# python
Python 3.7.12 (default, Jan  4 2022, 02:07:00)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import holidays
>>> h = holidays.UK(prov=None, state=None, years=[2020], expand=False)
>>>

Expericing same issue here.
import holidays
holidays.CountryHoliday('UnitedKingdom', years=[2022])

I got further before reaching the same error:
import holidays
import datetime

datetime.date(2022, 1, 1) in holidays.CountryHoliday('US') # True (works)

datetime.date(2022, 1, 1) in holidays.CountryHoliday('UK') # doesn't work; error as described in title

'1/1/2015' in holidays.CountryHoliday('UK') # also doesn't work; error as described in title

Fixed in beta.. thx everyone! 👍

authors: MarcSkovMadsen agorajek dr-prodigy garyng2

repo: dr-prodigy/python-holidays


text:
OrderedList does not respect "type" attribute

OrderedList appears to be setting list-style to none (via .drac-list), which causes the type attribute to not work.
e.g. why applying type="a" (for lowercase letters), the list still renders numbers.

From what I understand after a quick scan of the OrderedList styles, Dracula UI implements its own list styles for the OrderedList component, hence why there's a list-style: none on .drac-list. The list numbers are then basically re-implemented via a CSS counter(). Fortunately, I think we can get other numbering types by passing in another parameter to that counter() function!
The additional parameter for counter() is the same as a list-style-type property, which we can use in our OrderedList to get the same effect as the <ol>'s type attribute.
In the spirit of Hacktoberfest, I took my shot at trying to solve this issue! I think we can modify src/styles/list.css to accept a CSS variable as a second argument to the counter() function:
.list-ordered li::before {
  content: counter(li, var(--type, decimal))'.';
  /* the rest of the styles remain the same... */
}

Then we can create additional classes to set that --type variable. For example:
.list-ordered-lower-alpha {
  --type: lower-alpha;
}

.list-ordered-upper-alpha {
  --type: upper-alpha;
}

And then for the React component, we can also accept a type prop and then set one of the additional classes accordingly:
const orderedListTypes = {
  1: 'drac-list-ordered-decimal',
  a: 'drac-list-ordered-lower-alpha',
  A: 'drac-list-ordered-lower-alpha',
  i: 'drac-list-ordered-lower-roman',
  I: 'drac-list-ordered-lower-roman'
}

This is a temporary fix until we are able to have case-sensitive attribute selectors. Ideally we should be able to set the --type variable depending on the type attribute of the OrderedList component:
.list-ordered[type="a" s] {
  --type: lower-alpha;
}

.list-ordered[type="A" s] {
  --type: upper-alpha;
}

But that method only works on Firefox as of now, and for other browsers the type attribute selector is always case insensitive, resulting the styles for .list-ordered[type="a"] conflicting with .list-ordered[type="A"].

authors: Insidiae drewwyatt

repo: dracula/dracula-ui


text:
Issue #23: Apply root variables at html level

This prevents the app's dark theme styles in recent versions from overwriting it.
Before

After

This should address the issues raised in #23.

would love to have this finally fixed, this https://github.com/dracula/logseq/pull/24#event-12412732879 didn't seem to do the trick

authors: cballenar quickstar

repo: dracula/logseq


text:
RebornOS Linux Wallpaper

Not an issue but I created wallpaper for RebornOS - maybe You can use and add it.

Done: f761e88

authors: brandon-irs elkrien

repo: dracula/wallpaper


text:
kernel-patches: introduce kernel patch for fscache ondemand IO path o…

This is kernel patch for https://github.com/dragonflyoss/image-service/issues/714
before we figure out a formal solution for upstream, we should fix this performance issue , that may affect the user experience first.

Yeah, that is a practical approach.
The Linux community is generally reluctant to mix buffered and directed I/O, so we have to implement a direct I/O approach for upstream instead.

authors: hsiangkao kevinXYin

repo: dragonflyoss/image-service


text:
Pull requests are not displayed on pull-requests page

I have one pull-request in the repository, but during pull-requests page render it first shows up and in the end disappears.

I'm using the latest extension version. If I disable the extension, the pull-request is properly displayed.

Until the issue is fixed, you can disable PR filter in extension settings.
On Tue 10. 11. 2020 at 11:32, kirill-ianchuk notifications@github.com
wrote:

I have one pull-request in the repository, but during /pull-requests page
render it first shows up and in the end disappears.
[image: image]
https://user-images.githubusercontent.com/72520559/98662534-fc2f8900-2358-11eb-861c-5fee233a5915.png
I'm using the latest extension version. If I disable the extension, the
pull-request is properly displayed.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dragouf/Stash-Reviewers-Chrome-Extension/issues/74,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYJWAV3AHE27O4BOCUNIH3SPEJFTANCNFSM4TQPMOUQ
.

--
Rastislav Švarba

license: mit

license_source: bigquery


text:
Spec for chaosing caller saved registers

Currently in WP, we have specs for chaos-ing RAX if it used on the left hand side of a function being called. https://github.com/draperlaboratory/cbat_tools/blob/dc7b38179d23dbe8b47fe48a6f8e15c595b0627f/wp/lib/bap_wp/src/precondition.ml#L415
We should add more specs that allow us to:

always chaos RAX regardless if it was used on the left hand side of the target function
chaos the x86 caller-saved registers

Closed with #99


text:
Support https://raw.githubusercontent.com

Summary
What:
Alongside supporting deno.land and x.nest.land, add support for https://raw.githubusercontent.
Why:
So dmm can update dependencies imported from GitHub.
Acceptance Criteria
Below is a list of tasks that must be completed before this issue can be closed.

[ ] Write documentation (https://github.com/drashland/website/issues/225)
[ ] Write unit tests
[ ] Develop the feature

Taking on this issue? Read this before you get started.
If you take on this issue and the acceptance criteria does not make sense, post comments on this issue with your questions. Also, you can always hop in the Discord channel at https://discord.gg/c5R3sYuR to get help quickly.
Please read the Contributing Guidelines before starting this issue.

gonna work on it this, the faster we get it in the better

repo: drashland/dmm


text:
Storybook and unit tests

Hey!
I've smashed together a proof of concept for creating unit tests with storybooks. The stories can be used for demonstration purposes as well as testing the animation logic.

I've used yarn to set things up (storybooks doesn't work well with npm)
I don't fully understand what your dev workflow is yet, so I might have broken some things
You can start storybooks with yarn storybook
I've added two basic stories (a fade in and move to right animation)
I stub the requestAnimationFrame method to allow stepping through the animations
I've shown that the properties of the animated div can be inspected in a unit test

It's a very rough proof of concept, what do you think?

@wilcoschoneveld wow, thanks a lot, any kind of improvement to testing in general is a welcome addition. I normally use the examples wolder project for visual proofing, but that's fairly limited. I thought about snapshotting it, though. Other than that storybook could also be a nice tool for learning.
Do you plan to add some more stories to it? I'll def merge this and don't worry, nothing's broken. :-)

Good to hear! I'm going to try and find the time to work on this more regularly.
I added one fullscreen example to see how this would work in storybooks. I'm not yet sure how I can alias the 'react-spring' package to make the importing easier. How do you do this? Unfortunately there is a console warning when toggling this example but I haven't digged into the internals of react-spring to see whats going on, maybe you can have a quick look. Would you be ok to migrate all the examples to the storybook? I'm interested to hear what your development workflow is for this project. Maybe we could have a chat outside of this issue so we could do a quick questions and answers session.
I added a couple more stories. I think it would be cool to have a lot of small separate tests in the storybook as demonstrations but also to use as unit tests. However I haven't yet found a way to reliably stub requestAnimationFrame so that a single step is always the same duration in the spring. Again, I haven't dug that deep yet but it looks like animations depend on Date.now()? Maybe we need to make the animation timing functions pluggable so we can control it from unit tests. What are your thoughts on this?
I'm also trying to test Transition with enzyme mount but for now I can't get to the second child, small steps... 😄

@wilcoschoneveld the timing function actually is pluggable, you can readily exchange it.
import { Spring, Globals } from 'react-spring'
Globals.injectFrame(cb => global.requestAnimationFrame(cb), cb => global.cancelAnimationFrame(cb))

The current spring does depend on date.now(). Actually this is one of the things i want to look into. Right now that oscillator is a huge function with loops and whatnot ... but games usually use semi-explicit euler, which is really, really simple and probably faster as well. But i don't know what made Christopher Chedeau initially go for RK4 instead. Mysteries ...

Thanks for the snippet. I made the now function injectable as well and I got the tests to be reproducible. I'll create some tests and come back to you

@wilcoschoneveld sounds fantastic! Whenever you need this merged just ping me here.

I introduced react-testing-library and I'm very happy with the resulting test setup: toggle.test.js
Todo:

Remove deprecated test.js (it doesn't work now anyway)
Remove enzyme from react-spring
Setup jest runner so it is more developer friendly

Added more examples and removed enzyme
Todo:

Setup jest command for CI (with coverage)
Setup jest command for devs (watch, no coverage)
Port a couple more full screen examples

Tests started working again :-) How did you manage to get tests working without enzyme?
BTW, i've started a documentation using mdx based docz, i think it could well live side by side storybook. Docz leans more into documentation, storybook would be great for visual proofing/testing.

I added two more tests for the delay and immediate props. I'm happy with the current setup and I think it should function as a good basis for the test suite. I added package-lock.json to gitignore to indicate that we should only use yarn and the accompanied yarn.lock file.
I like the idea of docz, I'm interested to see how that would work out!
If you're ok with everything you can go ahead and merge 👍

authors: drcmda wilcoschoneveld

repo: drcmda/react-spring


text:
fix Cookie expires format.

Fix #1093

Please see the last comment in #1093, specifically:

DateTimeFormatter.RFC_1123_DATE_TIME is problematic, because days-of-the-month 0-9 are not prefixed by a 0 in RFC 1123 but they are in the HTTP specification (more discussion of this at https://stackoverflow.com/questions/7707555/getting-date-in-http-format-in-java)

The users default locale might not be English and output a month like 'Mai' instead of 'May'.

Both would be solved with
DateTimeFormatter.ofPattern("EEE, dd MMM yyyy HH:mm:ss O", Locale.ENGLISH).withZone(ZoneOffset.UTC)

DateTimeFormatter.ofPattern("EEE, dd MMM yyyy HH:mm:ss O", Locale.ENGLISH).withZone(ZoneOffset.UTC)

Thanks @Dennis4b, somehow I missed that part

Codecov Report

Merging #1288 (f9c53cf) into main (f28f686) will decrease coverage by 0.21%.
The diff coverage is 71.42%.

@@            Coverage Diff             @@
##             main    #1288      +/-   ##
==========================================
- Coverage   59.83%   59.61%   -0.22%
==========================================
  Files          70       70
  Lines        2450     2454       +4
  Branches       70       66       -4
==========================================
- Hits         1466     1463       -3
- Misses        984      991       +7

Impacted Files
Coverage Δ

zio-http/src/main/scala/zhttp/http/Cookie.scala
81.56% <71.42%> (-0.93%)
:arrow_down:

...io-http/src/main/scala/zhttp/service/Handler.scala
65.21% <0.00%> (-8.70%)
:arrow_down:

...http/service/server/ServerChannelInitializer.scala
78.26% <0.00%> (-4.35%)
:arrow_down:

...ain/scala/zhttp/service/ServerResponseWriter.scala
88.37% <0.00%> (-2.33%)
:arrow_down:

zio-http/src/main/scala/zhttp/http/HttpData.scala
81.81% <0.00%> (-1.52%)
:arrow_down:

Continue to review full report at Codecov.

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

@Dennis4b the proposed format is having issues in JDK8 that is the minimum version that we support. See the link in the previous comment.

I see. I need/use it to set a proper expiration date on cookies (i.e. one that browsers understand :-), haven't needed to parse such a timestamp yet so haven't run into any issues.
What are the options/possibilities for a different approach?

I see. I need/use it to set a proper expiration date on cookies (i.e. one that browsers understand :-), haven't needed to parse such a timestamp yet so haven't run into any issues.
What are the options/possibilities for a different approach?

I think the fastest solution is to drop support for JDK8 but as far as I'm aware there are still a lot of companies stuck on JDK8  for different reasons.

Sooo reading RFC 2616 closer there are actually 3 variants:
       HTTP-date    = rfc1123-date | rfc850-date | asctime-date
       rfc1123-date = wkday "," SP date1 SP time SP "GMT"
       rfc850-date  = weekday "," SP date2 SP time SP "GMT"
       asctime-date = wkday SP date3 SP time SP 4DIGIT
       date1        = 2DIGIT SP month SP 4DIGIT
                      ; day month year (e.g., 02 Jun 1982)
       date2        = 2DIGIT "-" month "-" 2DIGIT
                      ; day-month-year (e.g., 02-Jun-82)
       date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
                      ; month day (e.g., Jun  2)
       time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
                      ; 00:00:00 - 23:59:59
       wkday        = "Mon" | "Tue" | "Wed"
                    | "Thu" | "Fri" | "Sat" | "Sun"
       weekday      = "Monday" | "Tuesday" | "Wednesday"
                    | "Thursday" | "Friday" | "Saturday" | "Sunday"
       month        = "Jan" | "Feb" | "Mar" | "Apr"
                    | "May" | "Jun" | "Jul" | "Aug"
                    | "Sep" | "Oct" | "Nov" | "Dec"

For output the RFC1123+plus+leading+zero format can be used, but if we want to parse dates as well then all cases should be handled (so regardless of JDK8 it's not a complete solution).
The best options are probably:

Find appropriately licensed code which already solves this, or
Write a proper parser for the above grammar, or
Determine which variant is used via a simple string check, drop the trailing " GMT" (only GMT is allowed anyway), and use the appropriate (out of 3) java dateformatter without any O flags to avoid the JDK8 bug.

authors: Dennis4b codecov-commenter gciuloaica


text:
Update scalafix to 0.9.33

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

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "ch.epfl.scala", artifactId = "sbt-scalafix" } ]

labels: sbt-plugin-update, early-semver-minor, semver-spec-patch

Codecov Report

Merging #611 (f62ca03) into main (a657866) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #611   +/-   ##
=======================================
  Coverage   58.54%   58.54%
=======================================
  Files          59       59
  Lines        1399     1399
  Branches       52       52
=======================================
  Hits          819      819
  Misses        580      580

Continue to review full report at Codecov.

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

🚀🚀🚀 Benchmark Results
Concurrency: 256
Requests/sec: 446141.79

🚀🚀🚀 Benchmark Results
Concurrency: 256
Requests/sec: 431531.68

🚀🚀🚀 Benchmark Results
Concurrency: 256
Requests/sec: 438126.38


text:
Use Alpine based images

We should be using Alpine based images (https://github.com/gliderlabs/docker-alpine), which will reduce significantly the size overall.

I think using official images is far better than re-doing your own.

@docteurklein thanks for the reply, it's always great to have you around :)
Have you checked Alpine images? Comparing to the official images, these are the numbers:
REPOSITORY          TAG           IMAGE ID          VIRTUAL SIZE
gliderlabs/alpine   latest        157314031a17      5.03 MB
debian              latest        4d6ce913b130      84.98 MB
ubuntu              latest        b39b81afc8ca      188.3 MB
centos              latest        8efe422e6104      210 MB

It's quite amusing...

@drgomesp o/ hey there :)
yep, alpine brings interesting stuff, + a package manager for 5Mo.
I tried to make small images in the past too, but in the end, I prefer using official ones.
Almost every docker user has half the needed layers for a php image.
In the end, you only end up downloading a small diff, not the whole layers of the image.
Thanks to COW, having a big image shouldn't be a big deal.
Now that's all theoretic, and I often hate having to wait for image pulls.
Nevertheless, I try to stick with maintainers recommendations: "stick to official images" :)
Otherwise, the public hub would be full of duplicates.

@drgomesp Another advantage of using the official images is that people won't be lost when entering a container (they will have apt-get, bash, …). Entering alpine can be intimidating at first.
If you have some special php extensions to install, you'll need a lot of shared libs, and finding these in debian is more documented than alpine.
Anway that's just my 2 cents.
I can totally see advantages to alpine too (mainly size) but also security.

There was a post on HN recently which had some good arguments for and against alpine at https://news.ycombinator.com/item?id=10782897

I'm convinced at this point. Let's close this and move on.

Reopening this, since I think there's still some discussion worth having.
For reference: http://www.iron.io/blog/2016/01/microcontainers-tiny-portable-containers.html

@drgomesp so, apparently we will have both from the best worlds :)
It seems they are moving official images to alpine. \o/
https://www.brianchristner.io/docker-is-moving-to-alpine-linux/

I think we should make a distinction here between creating a dev box vs a prod box.
In my experience with docker as a dev box, its very likely that at some point you will enter the main symfony container and run commands inside there instead of using 'docker-compose run'.
And in that case i would prefer to have a full distro like ubuntu, mainly to feel "at home".
For the linked containers like databases etc.  it would be fine to use alpine, i guess.
Another consideration would be to at least have a common base distro and dont mix debian for mysql, ubuntu for nginx and f.e. fedora for symfony. At the moment we have debian for the symfony container and tutum uses ubuntu. I guess this could also save us some layers.

Closing as it doesn't really matter. We're using ubuntu since we're mainly focused on dev environment.

we're mainly focused on dev environment.

https://github.com/drgomesp/symfony-docker/blob/master/README.md

ready for development and production environments.

@sergeyklay I'll start to work on a distinction between dev and prod environments. For now, we're focused on having a full dev env working. Once we achieve that, we can focus on the production one.

but then you lose isomorphism (dev/prod parity)?

I guess we need to reopen this issue then, @docteurklein :)

authors: cigoe docteurklein drgomesp ivoba sergeyklay

repo: drgomesp/symfony-docker


text:
updated component description with selector usage

The docs for the HelloIonicPage are out of sync with the source code.
Added explanation for why the selector is useful even if the pages are loaded dynamically.

Thanks! :)

authors: andreiepure brandyscarney

repo: driftyco/ionic-site


text:
showWhen/hideWhen + [hidden]="" will fail

Short description of the problem:
When showWhen or hideWhen are used in addition to the [hidden]="" directive the component will be displayed even on the platform that it should remain hidden on.
For example, if hideWhen="ios" is used on a FAB button the FAB will not initially display on iOS. But if I add [hidden]="showFAB" to the button and then toggle the showFAB value using a button on iOS the FAB will be shown once the showFAB value is toggled back to true.
What behavior are you expecting?
A component with either showWhen or hideWhen should ignore the [hidden]="" directive so it won't be shown on the wrong platform yet still allows the component to be toggled on the correct platform.
Which Ionic Version? 2.x

Thanks for the issue! This will be fixed in the next release 2.0.0-beta.5. :smile:

repo: driftyco/ionic


text:
Move dependencies to angular 2.0.0-rc.6

Due to compatibility issues with other angular2 packages, there is a need to improve dependencies definition.

Closes @adamdbradley and @danbucholtz are working in branch https://github.com/driftyco/ionic/blob/ngmodule-build/package.json already fix this.

Hi @kevstessens, @ramonornela is exactly right.  This process is already underway and we hope to have more to share soon.  We have a branch here with all of our progress and changes if you want to follow along. I'm going to close this. We'll have RC6 in place as soon as we possibly can.
Thanks for pointing this out, @ramonornela!
Thanks,
Dan

Thanks @danbucholtz and @ramonornela !

authors: danbucholtz kevstessens ramonornela


text:
command [ionic platform add ios ] run wrong

i flowed the offical start document,and rebuild sever time s but  it is still not work

TypeError: Cannot read property 'hasOwnProperty' of undefined
    at Object.runr (/usr/local/lib/node_modules/ionic/lib/cli.js:191:19)
    at /usr/local/lib/node_modules/ionic/lib/cli.js:54:9
    at _fulfilled (/usr/local/lib/node_modules/ionic/node_modules/q/q.js:787:54)
    at self.promiseDispatch.done (/usr/local/lib/node_modules/ionic/node_modules/q/q.js:816:30)
    at Promise.promise.promiseDispatch (/usr/local/lib/node_modules/ionic/node_modules/q/q.js:749:13)
    at /usr/local/lib/node_modules/ionic/node_modules/q/q.js:557:44
    at flush (/usr/local/lib/node_modules/ionic/node_modules/q/q.js:108:17)
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Cannot read property 'hasOwnProperty' of undefined (CLI v2.1.7)

Your system information:

Cordova CLI: 6.4.0
Ionic CLI Version: 2.1.7
Ionic App Lib Version: 2.1.4
ios-deploy version: 1.9.0
ios-sim version: 5.0.11
OS: OS X El Capitan
Node Version: v7.0.0
Xcode version: Xcode 8.0 Build version 8A218a

it also do not work on windows ,android .

i figure it out by adding--v2 , but i think the offical document should update! it is really confused the document do not mentioned it

@aqnaruto but I think it does, at least in the documentation for the version 2.

This issue was moved to driftyco/ionic-cli#1657

authors: aqnaruto brandyscarney malvadeza


text:
Feature/update joke editor user interfaces

update the joke editor UI
now the players can actually read what the joke template is!
setup also shows on the punchline editor!

depends on: https://github.com/drigon01/MakeMeLaugh_GGJ24/pull/56

before actually merging this,
I want to try to make it a bit nicer.
now looking into the dragoon crasher example for the proper layout logic
and I want to understand why the vector imports failed ... :(


text:
evaluate_FlowFormer_tile.py has not attribute of MpiSintel_submission

Hi, thanks for this remarkable work. When I try to generate the Sintel submission results with evaluate_FlowFormer_tile.py, an error occurred: module 'datasets' has no attribute 'MpiSintel_submission'.  I checked the datasets.py and there is indeed no mention of this keyword or the implementation of this attribute. Looking forward to your reply.

Here is the MpiSintel_submission: https://github.com/drinkingcoder/FlowFormer-Official/blob/21be9d720b24310d1e739d044e812034ab875b33/core/utils/datasets.py#L104

Thank you for your clarification. Could you please briefly specify how class MpiSintel is different with MpiSintel_submission? The *.txt files are not available, making is difficult to understanding why there are two implementations for Sintel dataset. Thank you for your time.

authors: Huiimin5 drinkingcoder wyddmw

repo: drinkingcoder/FlowFormer-Official


text:
keep a changelog

think things are stable enough to start keeping a high-level changelog?
whenever we are, this is a not-entirely-terrible standard: http://keepachangelog.com/

so... are there releases? I can totally start a changelog file, but what's the version number ;-)

I think the current version number is either 61f6019409dad2bc83d5d53c85492bdf3f451b66 or 142, depending on how you count.
But now things have definitely become stable enough that it should be possible to keep it up to date and might even be worth doing versioned releases.

authors: driusan josephholsten

repo: driusan/de


text:
[FEATURE]: operation interceptor

Describe what you want
Do we have plans to let users define an operation interceptor to record query information such as table, operation, time cost, success/failure? Maybe like prisma's $extends which can extend all operations in a specific model.

yes, tracked in https://github.com/drizzle-team/drizzle-orm/issues/755

authors: dankochetov hytxxxxx

repo: drizzle-team/drizzle-orm


text:
[BUG]: Auto import does not work properly in some cases

What version of drizzle-orm are you using?
0.29.3
What version of drizzle-kit are you using?
No response
Describe the Bug
In some cases, drizzle-orm auto-imports do not work.
README explains how to reproduce:
https://github.com/jakeleventhal/drizzle-auto-import-repro/tree/main
Expected behavior
No response
Environment & setup
No response

strange one, we will take a look

I don't think it's drizzle related, so will close this one

@AndriiSherman turns out on pnpm@9.x.x this isn't an issue

authors: AndriiSherman jakeleventhal


text:
[BUG]: Drizzle-kit Introspection Failed to Declare Default Value in SQL

What version of drizzle-orm are you using?
0.29.4
What version of drizzle-kit are you using?
0.20.14
Describe the Bug
Table introspection fails to find a type declaration for a default value.
 ref_icon character varying(255) COLLATE pg_catalog."default" DEFAULT 'activity'::character varying,

Automatic SQL import does not occur and it imports without declaring it to be raw SQL.
import { sql } from 'drizzle-orm';
As a result several errors are created in the imported schema.
refIcon: varchar("ref_icon", { length: 255}).default('activity'::character varying`),

Expected behavior
Introspection must import SQL and make the statement as evidenced in the Documentation:
refIcon: varchar("ref_icon", { length: 255 }).default(
sql'activity'::character varying,
),
https://orm.drizzle.team/docs/indexes-constraints
Environment & setup
Node.js v20.10.0

Exactly the issue I got today too.

I have the same issue as well

authors: Caio-Tera DobroslavR dylanoldfield


text:
[FEATURE]: AsyncLocalStorage for transactions

Describe want to want
The idea is to use AsyncLocalStorage for automatically detecting transaction context, without using transaction object. Example how it should look like:
await db.transaction(async () => {
  await db.insert(users).values(newUser);
  await db.transaction(async () => {
    await db.update(users).set({ name: 'Mr. Dan' }).where(eq(users.name, 'Dan'));
    await db.delete(users).where(eq(users.name, 'Dan'));
  });
});

It can make the library easier to use, especially in case if database call is buried in call chain:
Instead of using this:
async createUser(dto, transaction?: ...) {
    await (transaction || db).insert(users).values(newUser);
}

User can write just this:
async createUser(dto) {
    await db.insert(users).values(newUser); // automatically detect that current request is in transaction
}

This sounds like a code readability and debugging nightmare. Current version provides much clearer picture of what is actually happening.

I did same thing in my kysely-orm library https://github.com/seeden/kysely-orm#transactions

Here is working example which I started to use
import { AsyncLocalStorage } from 'node:async_hooks';
import { drizzle } from 'drizzle-orm/postgres-js';
import { AnyPgTable } from 'drizzle-orm/pg-core';

type AfterCommitCallback = () => Promise<any>;

export default function database(db: ReturnType<typeof drizzle>) {
  const asyncLocalStorage = new AsyncLocalStorage<TransactionState>();

  type DatabaseType = typeof db;
  type Transaction = Parameters<Parameters<DatabaseType['transaction']>[0]>[0];

  type TransactionState = {
    transaction: Transaction;
    committed: boolean;
    afterCommit: AfterCommitCallback[];
  };

  type TransactionResponse = {
    transaction: Transaction;
    afterCommit: (callback: AfterCommitCallback) => void;
  };

  type TransactionCallback<Type> = (trx: TransactionResponse) => Promise<Type>;

  function selectAll() {
    return db.select();
  }

  function select<SelectedFields extends Parameters<DatabaseType['select']>[0]>(selectedFields: SelectedFields) {
    return db.select(selectedFields);
  }

  function dbSelect(): ReturnType<typeof selectAll>;
  function dbSelect<SelectedFields extends Parameters<DatabaseType['select']>[0]>(selectedFields: SelectedFields): ReturnType<typeof select>;
  function dbSelect<SelectedFields extends Parameters<DatabaseType['select']>[0]>(selectedFields?: SelectedFields) {
    return selectedFields ? select(selectedFields) : selectAll();
  }

  return {
    delete: <Table extends AnyPgTable>(table: Table) => db.delete(table),
    insert: <Table extends AnyPgTable>(table: Table) => db.insert(table),
    update: <Table extends AnyPgTable>(table: Table) => db.update(table),
    select: dbSelect,
    transaction: async <Type>(callback: TransactionCallback<Type>) => {
      const transactionState = asyncLocalStorage.getStore();
      if (transactionState && !transactionState.committed) {
        console.log('you are already in transaction. using current transaction instance');
        return callback({
          transaction: transactionState.transaction,
          afterCommit(callback: AfterCommitCallback) {
            transactionState.afterCommit.push(callback);
          },
        });
      }

      const afterCommit: AfterCommitCallback[]  = [];

      const result = await db.transaction((transaction) => {
        const newTransactionState: TransactionState = {
          transaction,
          committed: false,
          afterCommit,
        };

        return new Promise<Type>((resolve, reject) => {
          asyncLocalStorage.run(newTransactionState, async () => {
            try {
              const result = await callback({
                transaction,
                afterCommit(callback: AfterCommitCallback) {
                  newTransactionState.afterCommit.push(callback);
                },
              });
              resolve(result);
            } catch (error) {
              reject(error);
            } finally {
              newTransactionState.committed = true;
            }
          });
        });
      })

      for (const afterCommitCallback of afterCommit) {
        await afterCommitCallback();
      }

      return result;
    },
  };
}

mikro-orm also supports this feature. it would be great to see it here.

Here is working example which I started to use

Please help me understand the feature request here.
You would like to replace the db returned by the drizzle function like this:
const drizzleDb = drizzle(...);
export const db = database(drizzleDb)

And then use the exported db everywhere in the codebase how?
Is the idea to call db.transaction deep in a stack of calls and only using one transaction?

Is the idea to call db.transaction deep in a stack of calls and only using one transaction

Yes, all database operations down the stack will be part of that transaction without directly using the transaction object ‘tx’. Just wrap a batch of functions in a transaction, and everything else will automatically become part of that transaction.
Pros:

There’s no need to write separate functions for operations within and outside of transactions, as illustrated in the createUser example.
It reduces the likelihood of errors where write operations are mistakenly executed directly without a transaction (tx).

Cons:

all pitfalls of AsyncLocalStorage

You would like to replace the db returned by the drizzle function like this:

I’m not certain if this is the best solution for the problem, but I would like to have an option to configure that behavior globally

Here is working example which I started to use

Please help me understand the feature request here. You would like to replace the db returned by the drizzle function like this:
const drizzleDb = drizzle(...);
export const db = database(drizzleDb)

And then use the exported db everywhere in the codebase how? Is the idea to call db.transaction deep in a stack of calls and only using one transaction?

i would not make it necessary to use a separate function to wrap the db object. invocations on db should just use async local storage to check wether there is an encompassing transaction (created with db.transaction(...)) and use it thus making it transparent to the user.

What is the advantage of using a node API over using a state variable saved inside the class returned by the drizzle function?
Also, other that the convenience, is there an advantage of using the same transaction for all your operations as opposed to nested transactions that would probably have savepoints?
My other observation is that this feature would also introduce hidden behavior, I would honestly prefer another API, like db.uniqueTransaction. This will both prevent any breaking changes and make it have a clear intent.

you're right about introducing hidden behavior. it could be opt-in.
the benefit, in my experience, is being able to:

invoke re-usable methods exported from other modules that run their own queries + business logic, etc, without having to pass around a tx param everywhere.
these queries might be reads or writes, but imagine reads (selects) where you would want them to transparently run inside the current tx if there is one due to transaction isolation level.
when working with a team of developers on a complex app, i as a lead would feel more confident that my juniors are respecting transaction contexts by not relying on them remembering to pass that tx param around.

by opt-in i mean a global setting, not changing the api or introducing a new method.

The following is my personal opinion, not endorsed by anyone, especially the drizzle team:

Relying on a node API would immediately complicate the possible support for deno, hermes, and any other possible environments/runtimes with no/little support for AsyncLocalStorage.
I would personally prefer passing tx/db around than having a global magic state that morphs a db call to make it run either in a transaction or a regular connection depending on the state of my application. This will basically serialize all my database transactions in one single connection. I'm team dependency injection over global state when possible.
The tx object is a class that extends the db returned by the drizzle function, the methods are all the same except for tx.rollback() which you don't really need because all it does is throw an error. That means that in OP's example, you can make the db object required, and it would work with a tx.

async createUser(dto, db: typeof db)

I obviously don't know the structure/requirements of your projects but I feel like making the db globally available and let it have an internal state that can be used in the same way as proposed with AsyncLocalStorage is a better pattern.
Also, introducing a new method will provide the flexibility to make this pattern opt-in per request.

Well, tbh, I am not sure of a use-case for making database queries outside of a transaction in the current async call stack if one exists. If I saw that in a code base I would assume it's a bug and not intended, yet it is so easy to make the mistake. If this is true, it would make sense for the ALS proposal to be the default behavior, or at the very least it should be an option.
@Angelelz if it were opt-in, your projects would not need updating.
I am not sure of drizzle's goals in terms of support runtimes, but I know that Bun supports ALS.

additionally, the preference for passing the db/tx object around seems at odds even with drizzle's own documentation. for example at https://orm.drizzle.team/docs/sql-schema-declaration/#:~:text=Database and table explicit entity types you see the following:
const db = drizzle(...);
const result: User[] = await db.select().from(users);
export async function insertUser(user: NewUser): Promise<User[]> {
  return db.insert(users).values(user).returning();
}

here you can clearly see the intent is to create a global db object that is imported and used directly in your functions without receiving it as a parameter. so having to declare db parameters everywhere and passing the db or tx around seems to not be aligned with the spirit of the library's design.

Well, tbh, I am not sure of a use-case for making database queries outside of a transaction in the current async call stack (single http request) if one exists.

In the context of a backend server, which seems to be the context you are referring to, I can think of many examples where it wouldn't only be undesirable but actually counterproductive to have all the db queries serialized in a transaction:

SSR server getting all the data for an admin dashboard (possibly from many different unrelated tables).
Writing to tables unrelated to the operation being performed in the request, like logs or analytics.
This is one of the reasons pools exists.
In other contexts, there are many many other examples.

I am not sure of drizzle's goals in terms of supported runtimes, but I know that Bun supports ALS.

Neither am I, but looking at the codebase and the history, drizzle can easily run in the browser, an electron app, a react-native app, on the edge, in a worker thread, etc. etc. And there is an actual issue opened by one of the team members to support deno.

the preference for passing the db/tx object around seems at odds even with drizzle's own documentation.

I did say that my opinion was my own. But I think it's quite the opposite, drizzle is a zero dependency library because of the fact that it uses dependency injection: You have to give it the driver.
In any case, if this feature is important, gains traction, and the team agrees, it could be easily implemented by also using dependency injection:
const db = drizzle(myDriver, { schema, logger, transactionStorage })

Where transactionStorage can be a wrapper (possibly provided by drizzle) of AsyncLocalStorage.

Relying on a node API would immediately complicate the possible support for deno, hermes, and any other possible environments/runtimes with no/little support for AsyncLocalStorage.

FYI deno supports AsyncLocalStorage

authors: Angelelz guy-borderless hyzyla kibertoad rhyek seeden


text:
Splash screen

Description
I have been able to add the splash screen for the app.  I have also updated the path for the assets on app.json since they were wrong.
Fixes #7
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?
To test the changes I have been able to run the app on expo and the splash screen is displayed. I am not good with storybook so I have not been able to write any tests  for this.

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

@brianwachira you can review this 🙏🏽

@brianwachira I have been able to resolve the issues that you had raised


text:
[Feature] 修改Helm部署为Operator模式

Is your feature request related to a problem? Please describe.
Helm 部署为一次性的全局安装，并不会对当前集群的状态做持续性的运维管理。
建议后面将Helm部署逐步迁移为Operator形式，这样可以做到完全云原生的资源全生命周期管理。
Describe the solution you'd like
目前可以使用go-client的客户端实现，不过考虑到技术栈的统一性，我个人建议使用 java-opeartor-sdk来实现。
Describe alternatives you've considered
实际大数据生态中已经有很多组件已将实现了Operator，比如 Spark-Operator, Solr-Operator, Cassandra-Operator, Flink-Operator。
在条件成熟的时候都可以引入作为技术备选。
Additional context
NA

cloudeon最新版没有使用helm部署组件

repo: dromara/CloudEon


text:
是否支持持久化

是否考虑支持持久化？很多场景这是个硬需求呢

指的是编排规则持久化吗？  后续开放dashboard平台进行配置持久化和监控相关功能。

task的持久化，如果task执行的机器意外宕机，重启后可以继续执行

规则配置本身就是在配置文件中写好的，你的意思应该是任务状态执行过程中宕机的话是不支持维护这个状态的

过程中宕机的话是不支持维护这个状态的

https://github.com/ponfee/distributed-scheduler

authors: Memorydoc ponfee visionarywind

repo: dromara/gobrs-async


text:
delete redundant code, refactor onRuleChanged method

// Describe your PR here; eg. Fixes #issueNo
fixes #1049
This PR does two things:
Firstly, the redundant method named 'updatexxxMap' in NacosDataChangeLlistener listener is deleted. These methods are not useful in data synchronization.
Second, in 'onRuleChanged' method, old data will be cached. In the long run, there will be more and more rule related cache data, which will affect the performance. The cache processing logic of this method has been modified. When new data comes, it will be directly added to the cache, and when the original data is modified, it will be covered.
Finally, the modified code has been verified and the function is normal.

Make sure that:

[x] You have read the contribution guidelines.
[x] You submit test cases (unit or integration tests) that back your changes.
[x] Your local test passed mvn clean install -Dmaven.javadoc.skip=true.

Codecov Report

Merging #1058 (7e70e02) into master (b3bafa9) will decrease coverage by 0.81%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #1058      +/-   ##
============================================
- Coverage     74.31%   73.49%   -0.82%
+ Complexity     2048     2025      -23
============================================
  Files           355      355
  Lines          7846     7796      -50
  Branches        858      848      -10
============================================
- Hits           5831     5730     -101
- Misses         1578     1637      +59
+ Partials        437      429       -8

Impacted Files
Coverage Δ
Complexity Δ

...admin/listener/nacos/NacosDataChangedListener.java
97.69% <100.00%> (+1.02%)
36.00 <1.00> (-13.00)
:arrow_up:

...soul/client/sofa/SofaServiceBeanPostProcessor.java
18.91% <0.00%> (-41.90%)
5.00% <0.00%> (-4.00%)

...soul/client/tars/TarsServiceBeanPostProcessor.java
19.17% <0.00%> (-27.40%)
5.00% <0.00%> (-5.00%)

.../metrics/facade/handler/MetricsTrackerHandler.java
91.07% <0.00%> (-3.58%)
23.00% <0.00%> (-1.00%)

.../soul/plugin/httpclient/NettyHttpClientPlugin.java
57.14% <0.00%> (-2.05%)
10.00% <0.00%> (ø%)

...omara/soul/sync/data/http/HttpSyncDataService.java
70.58% <0.00%> (ø)
12.00% <0.00%> (ø%)

...elimiter/handler/RateLimiterPluginDataHandler.java
74.13% <0.00%> (ø)
12.00% <0.00%> (ø%)

Continue to review full report at Codecov.

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

Codecov Report

Merging #1058 (7e70e02) into master (b3bafa9) will decrease coverage by 0.81%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #1058      +/-   ##
============================================
- Coverage     74.31%   73.49%   -0.82%
+ Complexity     2048     2025      -23
============================================
  Files           355      355
  Lines          7846     7796      -50
  Branches        858      848      -10
============================================
- Hits           5831     5730     -101
- Misses         1578     1637      +59
+ Partials        437      429       -8

Impacted Files
Coverage Δ
Complexity Δ

...admin/listener/nacos/NacosDataChangedListener.java
97.69% <100.00%> (+1.02%)
36.00 <1.00> (-13.00)
:arrow_up:

...soul/client/sofa/SofaServiceBeanPostProcessor.java
18.91% <0.00%> (-41.90%)
5.00% <0.00%> (-4.00%)

...soul/client/tars/TarsServiceBeanPostProcessor.java
19.17% <0.00%> (-27.40%)
5.00% <0.00%> (-5.00%)

.../metrics/facade/handler/MetricsTrackerHandler.java
91.07% <0.00%> (-3.58%)
23.00% <0.00%> (-1.00%)

.../soul/plugin/httpclient/NettyHttpClientPlugin.java
57.14% <0.00%> (-2.05%)
10.00% <0.00%> (ø%)

...omara/soul/sync/data/http/HttpSyncDataService.java
70.58% <0.00%> (ø)
12.00% <0.00%> (ø%)

...elimiter/handler/RateLimiterPluginDataHandler.java
74.13% <0.00%> (ø)
12.00% <0.00%> (ø%)

Continue to review full report at Codecov.

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

authors: Zhoutzzz codecov-io

repo: dromara/soul


text:
Display login failure messages

When using Drone with GitLab and using invalid credentials, the page shows a white screen.
It would be helpful for the end user if there was an error message shown.

Should this bug still be assigned to milestone v0.3.1 if #814 was closed? Will the new UI be implemented for v0.3.1?

I get this error even when I'm already signed into Github with correct creds

what do you see in the logs? Each potential error path in the authorization code is logged to help correctly identify the issue. There could be a number of problems. You could have closed registration enabled, org restrictions, incorrect redirect URL mismatch with your GitHub settings and more. The logs will indicate which issue is being encountered.

+1

Log
2015/07/29 19:55:31 Error exchanging token. OAuthError: updateToken: Unexpected HTTP status 404 Not Found
2015/07/29 19:55:39 Error matching state in OAuth2 redirect

this has been fixed in the 0.4 branch, so I'm closing

authors: bradrydzewski brunowego bscott mattbostock nils-werner

repo: drone/drone


text:
JBPM-3106 (2nd try): seperating EM initialization from db operations in o

JBPM-3106 (2nd try): seperating EM initialization from db operations in order to have all operations within tx's.
The first effort to fix this problem caused other problems:

see https://github.com/droolsjbpm/drools/commit/5f452c93637d889804f3a48b268c87f67560f004#commitcomment-595711

The changes in this pull request make sure that EM initialization -- which can be done by spring, are done outside of a transaction, while all db operations are done within a tx. This is to ensure postgreSQL compatibility, since the SessionInfo object contains a @LOB, which Postgres will store (via the Large Object facility) in 2 tables -- thus requiring a tx for all operations doing anything with a SessionInfo object.

Please cherry-pick this to 5.3 as well.

repo: droolsjbpm/drools


text:
can not find import class

Hi
@Salaboy , I build current mast branch , I find here https://github.com/droolsjbpm/jbpm-console-ng/blob/master/jbpm-console-ng-generic/jbpm-console-ng-data-filters-client/src/main/java/org/jbpm/console/ng/df/client/filter/json/DataSetLookupJSONMarshaller.java#L23
This class not exist in dashbuild. Maybe it was be remove. so I can not maven build jbpm-console-ng.
Please check it.
Thanks!

@cristianonicolai Please check it.

Hi @bxf12315, there should be a PR to fix this problem coming out any soon. @nmirasch is working on it.

@cristianonicolai @nmirasch  Thanks , If you need my help, please feel free to let me know

It should be close, because of  @nmirasch fixed

repo: droolsjbpm/jbpm-console-ng


text:
Error Implementing Dropwizard Logging with Appenders using Gradle

Hi I am trying to implement file and console logging with dropwizard. I have followed the docs and configured my config file as below.
logging:
level: INFO

appenders:
     -type: console

When I tried to run the server I am getting the below error.
**configuration.yml has an error:
Failed to parse configuration at: logging.appenders.[0]; Could not resolve type id 'console' into a subtype of [simple type, class io.dropwizard.logging.AppenderFactory<ch.qos.logback.classic.spi.ILoggingEvent>]: known type ids = [AppenderFactory]
at [Source: N/A; line: -1, column: -1] (through reference chain: com.whatever.Main["logging"]->io.dropwizard.logging.DefaultLoggingFactory["appenders"]->java.util.ArrayList[0])**

I am constructing the fatJar like below.
task fatJar(type: Jar) {
manifest {
    attributes 'Implementation-Title': 'Creating fatJar for Whatever',
            'Implementation-Version': version,
            'Main-Class': 'com.whatever.Main'
}
baseName = project.name + '-all'
from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
with jar
}

I tried this link as suggested in this group. And I am not sure how to proceed.

@ganeshcse2991 As you've already discovered, you need to merge the file from META-INF/services in your custom fat JAR.

Can you help me on how to do it?
On Oct 6, 2016 6:07 PM, "Jochen Schalanda" notifications@github.com wrote:

Closed #1759.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@ganeshcse2991 See https://www.yunspace.com/post/dropwizard-gradle-build-with-shadowjar/ for an example

repo: dropwizard/dropwizard


text:
Timers with exponentially-decaying reservoirs

I've used Timers for meter API calls with different frequency which is chaging over time. I faced up problem with some metrics with low calls count, that old metrics are kept for very long time. In result, graphs in Graphite show inaccurate values - old ones.
The problem has been described in this article "Don’t use Timers with exponentially-decaying reservoirs in Graphite' (http://taint.org/2014/01/16/145944a.html).
Author said that:

In reality, if the frequency of updates to such a timer drops off, it could take a lot longer, and if you stop updating a timer which uses this reservoir type, it’ll never decay at all. The GraphiteReporter will dutifully capture the percentiles, min, max, etc. from that timer’s reservoir every minute thereafter, and record those to Graphite using the current timestamp — even though the data it was derived from is becoming more and more ancient.

Workaround suggested by author is:

What we eventually did in our code was to use this Reporter class instead of GraphiteReporter; it clears all Timer metrics’ reservoirs after each write to Graphite. This is dumb and dirty, reaching across logical class boundaries, but at the same time it’s simple and comprehensible behaviour: with this, we can guarantee that the percentile/min/max data recorded at timestamp T is measuring events in that timestamp’s 1-minute window — not any time before that. This is exactly what you want to see in a time-series graph like those in Graphite, so is a very valuable feature for our metrics, and one that others have noted to be important in comparable scenarios elsewhere.

What is your reccomendation to deal with such problem?

@joschi  Yes, you're right. L'm sorry - I'm new on github.
Is it possible to move this issue, or should I close this issue and open another in https://github.com/dropwizard/metrics ?

This issue was moved to dropwizard/metrics#1223


text:
Add a basic test for DefaultHealthFactory#configure()

This method is fairly tricky to test, but previously had no coverage. Ideas to make this test better would be appreciated.
Part of a mini-quest to kill that Sonar error about not meeting 80% test coverage on new code.

This took the sonar coverage state for new code from ~70% to 73.6%


text:
GraphiteReporter builder does not allow to set executor

When using Metrics GraphiteReporter in Java EE environment with metrics-cdi it's quite important to use executor service provided by the container
    @Inject
    private MetricRegistry metricRegistry;

    @Resource
    ManagedScheduledExecutorService executorService;

    GraphiteReporter reporter = GraphiteReporter.forRegistry(metricRegistry)
                                                      .withExecutor(executorService)
                                                      .build(graphite());

But as of now, GraphiteReporter builder does not allow to set executor  and neither does GraphiteReporter constructor.

Is it not sufficient to tie the reporter instance to the lifecycle by creating a @PreDestroy method to call close() on the reporter?

I don't think it is sufficient to tie the reporter to the lifecycle of the @PreDestroy method because thus the ExecutorService as a resource cannot be managed by the container. You could make use of the administration and monitoring features of the container if you used the injected ExecutorService and allow for runtime parameter changes.
I suggest you take a look at changes #1018 from @vladimir-bukhtoyarov. They are pretty simple and straight forward.

repo: dropwizard/metrics


text:
Error installing certinal

Following the installation directions I'm confronted with:
bin % go get -u github.com/jteeuwen/go-bindata/...
bin % go get github.com/drtoful/certinel
# github.com/drtoful/certinel/app
../src/github.com/drtoful/certinel/app/http.go:153:15: undefined: Asset

pretty new to golang so I can't really troubleshoot this as much as I normally would before filing an issue.
any help would be appreciated.
trying to install on:
go version go1.11.1 linux/amd64
ubuntu 16.04

I was able to install it following these directions:
go get -u github.com/jteeuwen/go-bindata/...
go get github.com/drtoful/certinel
go generate github.com/drtoful/certinel
go install github.com/drtoful/certinel

I still got the error, but was able to ignore it.

@nwhobart @ImNtReal Heads up, https://github.com/drtoful/certinel/pull/4 got merged today, which removes the dependency on go-bindata, which was at the root of this problem/error... The change requires that it be compiled with Go 1.16+, but does simplify the compile steps. I've ensured that the README in this repo is up to date with the current steps to compile certinel.

authors: ImNtReal TyBrown nwhobart

repo: drtoful/certinel


text:
Ensure ddev is properly utilizing Semantic Versioning

What happened (or feature request):

Clarification

What you expected to happen:

Ensure our roadmap and release strategy is fully compliant with http://semver.org/.

The good news is we actually are fully compliant!
items #4 and #5 from semver.org:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

tl;dr: since we're pre-1.0.0, anything is permissible. This has been (at least on my part) purposeful, as needing to track breaking changes as things have been moving so fast hasn't seemed worth the effort. We are approaching a phase of feature 'completion' and relative stability, though.
I think the meat of this ticket is actually determining where our 1.0.0 should be, and then ensuring we're more diligent about being accurate with respect to major/minor/patch releases after that.

@beeradb Agreed with everything you said regarding focusing on how this impacts post 1.0.0. One small logistical/admin item is to update the roadmap versions to include both decimal points and probably be a little more careful on what's truly 1.1.0 and 1.2.0 until we've evaluated if/when APIs change.

While not completely related to this, there were other point releases that didn't have an official milestone attached. I might want to back create it so that we have better linking to issues and when they were released along the roadmap.

So having thought through this it a bit more and going back to source reference material, I think this impacts us in the following ways.

Technically, we've been adopting a "v" to prepend the version number to provide a visual queue to an end-user that this is a version number and not something else. Techncially this isn't true semver and it's assumed that "v1.2.3" would be an acceptable tag with the assumed semver number of "1.2.3". See https://github.com/semver/semver/blob/master/semver.md#is-v123-a-semantic-version as a reference.
Branches. I envision a time when we want to get a major item reviewed and committed while also not being ready to officially incremement to a new major release. I'm therefore assuming that we will want to adapt our workflow to include a second branch one major release ahead for these situations, although that might become untenable depending on how much drift occurs.
Reviews. We will probably need to have as part of our code and end-user review process a confirmation that no major backward-incompatible BC's were introduced. Otherwise, this is all for show and we're not going to hold ourselves accountable. Since we already have an official review process for releases, I suggest we add our fail-safe reviews there as the final stop gap, although that might be challenging because it's already committed to master and essentially forcing a major version bump or a revert of the changes. In that case, we may need to require this as part of our code reviews per feature.
Release Notes. For major releases where incompatible changes and deprecation occur, we need to have a more robust means of communicating those changes in our release notes.

From an issue scope perspective, I think this boils down to:

Do we commit to this publicly? Default answer: yes.
Do we maintain a branch open for next major release? Default answer: yes.
Where do we document? Default answers: our commitment in our community guides and the process in our review requirements.
Do we drop the "v" label in our versioning? Default answer: yes unless we feel this adds enough value.

Open to feedback from anyone on the team. I would also like a thumbs up from at least @cyberswat or @beeradb on the technical items and my default answers to the questions above. Once approved I'll open a PR on the suggested doc changes (if applicable) as well as update our milestone labeling moving forward.

I don't have a particular attachment to the 'v' prefix, but github seems to, see https://github.com/drud/ddev/releases/new  (instructions). I can't remember or never knew why this is.  But we explicitly switched to the 'v' because if this issue I think.

Good to know because I didn't recall that tidbit from our history. FWIW, I prefer maintaining v just because it always prompts me to think "version".

Based on a quick internal discussion. It seems like maintaining the "v" is preferred because 1) we've been doing it already 2) other very popular and semver compatible projects like Kube also use it 3) it doesn't hurt us or give us anything truly important by dropping.

Updated issue summary to reflect the one remaining action (documentation in our readthedocs and community guidelines).

While I'm unwavering on the decision to proceed with Semver support, it's curious to hear dissenting voices. Posting for posterity...

https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e
http://akkartik.name/post/versioning

PRs merged. Closing!

No comments on why this might have been reopened, so I'm closing it.

Re-opened so we can update our documentation :)

As per an internal conversation, the gains of fully committing to semver is not readily apparent and is creating some artificial dependencies. To that tend, we will revert the PRs in our community docs and DDEV documentation that explicitly state support. Then we can consider this closed.

As in slack, I don't think we've finished this conversation, and I don't even think it's a valid conversation for ddev (semver does not even apply to a tool like semver, IMO). ddev is not a library that you build against.  I think we're free to pursue any line of releases that tries to keep our customers happy. Baffled how we're still not communicating about this after a year of conversations.

We'll consider this closed.

authors: beeradb rfay rickmanelius

repo: drud/ddev


text:
ddev snapshot restore should take either full name of snapshot or shortname

Describe the bug

I can no longer restore snapshots with the same name I used when I created them.
Previously, (up until ddev v.1.18), I could backup and restore snapshots with these commands:
Create new snapshot - ddev snapshot -n name_of_snapshot
Restore a snapshot - ddev snapshot restore -n name_of_snapshot
In ddev v1.19 alpha3, the snapshot's name has a new suffix, of the db-type and db-version:
e.g. name_of_snapshot-mariadb_10.3.gz
To Reproduce

Run these commands, in ddev v1.18 it works, but in ddev v1.19 that functionality is broken -
ddev snapshot -n hello-world
ddev snapshot restore -n hello-world
Expected behavior

Similar to version 1.18, I think users expect using the same name in snapshot backup and restore commands.

I agree this is some friction that should be removed.

authors: rfay shaal


text:
v1.1.0 Release Checklist Due 2018-08-13

Remaining actions:

[ ]  Review release (product owner)
[ ] Approve release (product owner and release manager)
[ ] Create binaries (any DRUD maintainer)
[ ] Draft release notes (release manager)
[ ] Draft additional announcements for blog, newsletter, etc (not applicable at the moment)
[ ] Create release (release manager)
[ ] Update Roadmap (TPM/release manager)
[ ] Followup issues spun off if we need them.

For additional background information, please see our Product Release instructions here.

Artifacts for testing v1.1.0 are at https://circleci.com/gh/rfay/ddev/637#artifacts/containers/0

Current diff https://github.com/drud/ddev/compare/v1.0.0...HEAD

Based on the release notes and diff, I believe these are the end-user features to focus on.

files-import
drud-s3 pluging
covert to docker volumes, snapshotting
memcached
hostname clean ups
drush on host machine

Luckily, all but one I've tested before at some level. The drush command is the only one I'll be using for the first time.

Here is my working copy so far.
ddev v1.1.0 Review
Executive Summary
Based on the following analysis, ddev v1.1.0 is not ready for release.
Milestone Overview (@TODO)
@TODO
Testing
Performed by Rick Manelius as of 2018-08-14
Hardware Setup
I’m using a laptop with the following high-level specifications:

MacBook Pro: Retina 15-inch Mid 2015
2.2 Ghz Intel Core i7
16 GB 1600 MHz DDR3 RAM
250 GB Hard Drive
macOS Sierra 10.12.4

Software Setup

Xcode
Docker 18.03.1-ce
Git 2.15.1

Repositories Used

Preparation

TODO

Results
To Test

files-import
drud-s3 pluging
covert to docker volumes, snapshotting
memcached
hostname clean ups
drush on host machine

Working
Needs Work
Decisions
Based on the following analysis, ddev v1.1.0 is not ready for release.
Recommendations

TODO

Noting something that came up in my testing. I'd like to get ahead of that...

files-import

Set up Drupal 7.59 w/defaults.
drush site-install standard --db-url=mysql://db:db@db/db -y
Verified working D7 site
Created a drush site archive with ddev exec drush ard
Attempt 1: Interfactive

ddev import-files

Recommendation: Add "source" to the instructions to help delineate that this is not the destination path or the path to import. That is: "Provide the path to the source directory or archive you wish to import."
Properly failed if I added an incorrect filename with "Failed to import files for drupal-7.59: invalid asset: file not found"
Properly identified the file

REGRESSION. I thought we used to have a prompt for the --extract-path string?

Attempt 2: Flags

Invalid archive and extract path

ddev import-files --src file.txt --extract-path blah => "Failed to import files for drupal-7.59: invalid asset: file not found"

Valid archive, invalid extract path

ddev import-files --src db.20180815_104847.tar.gz --extract-path blah => Reports "Successfully imported files for drupal-7.59"

ISSUE. An invalid path should not result in a success message. We should confirm the path exists and, if not, tell the user the path is wrong.

Valid archive, valid extract path

ddev import-files --src db.20180815_104847.tar.gz --extract-path html => Success message and this worked.

Things not tested

All archive formats (previously confirmed tar, gzip, and tar.gz)
Directories instead of archives.

FAILED.

I feel strongly that the success message for an invalid path needs to be a warning/error and not a success.
I think the interative prompt needs the extract-path. Coupled with the incorrect success message (previous bullet), it's hard for an end-user to debug when there is 1) no way to add that flag and 2) they are getting a false positive.

Completed reviews on 4 of the 6 items. May have to wait a few hours until I get back to the rest.

Done with my review. As noted, there is one fail (IMHO) and two recommendations. I know import-files is also not a typical end-user feature, so if this is simply not something we can turn around in a day, I'm good with filing a followup issue for the next sprint and still approving the release. The other features are still working and I'm happy how this release has turned out!

BTW, based on the latest PR... we are approved for release.

over to me to update roadmap, close milestone and roll out next release issue checklist

updated the wiki roadmap page; created next release checklist
closing this, the milestone and the board

authors: dclear rfay rickmanelius


text:
Fix typo

The Problem/Issue/Bug:
How this PR Solves The Problem:
Manual Testing Instructions:
Automated Testing Overview:

Related Issue Link(s):
Release/Deployment notes:

You are a sharp one. Thanks!

authors: josefglatz rfay


text:
fix SketchMergeAggregatorFactory.finalizeResults and  comparator

originally reported in https://groups.google.com/forum/#!topic/druid-user/1Fk14weuwUM
more UTs are added to catch various errors with different query types
this is a regression so I have set the milestone is set to 0.9.2

I believe there is still a bug related to topN queries and the Comparator returned by the SketchAggFactory.

@cheddar hmmm... let me add an UT for topN as well

@himanshug please test with all query types including groupBy as well

@cheddar  added UT for topN and fixed the comparator
@fjy yeah, groupBy test existed already but updated that to be run on multiple segments and merged instead of just one
there is another pending optimization that i discussed with @cheddar  today, that is to cache the union estimates to avoid conversion multiple times due to multiple comparison calls in topN query processing. I will do that in a separate PR for 0.9.3 and this PR is only to fix regression and to be backported to 0.9.2 .

👍

👍

@himanshug please backport

@fjy backport pr https://github.com/druid-io/druid/pull/3621

authors: cheddar fjy himanshug

repo: druid-io/druid


text:
Feature request: Score the collective team utility level

I think it would be great to draw inspiration from lhm.gg where they have this:

It shows a 'Team utility level' above the player stats as an aggregated value, which provides a quick at-a-glance of the teams economy and opportunity going into the round.

I'm personally not really interested in this currently, but will keep this open if anyone else wants to create a PR or in case I change my mind :D
@ReneRebsdorf Do you have suggestions on cutoffs for the levels?

@drweissbrot
Sorry, I totally missed you asked for feedback on cutoff levels :-(
Here's a screenshot from a competitor over at lexigrine and JohnTimmermann/Custom-CS2-Hud

My suggestion:

Level
Value

Bad
0

Neutral
2000

Good
3000

Great
5500

A full inventory costs 6500 for CTs and 6000 for Ts, if each player only buys one flash.
It is not uncommon for some players to carry 2 flashbangs for executes, so I think it would be better to lower it to 5.500
I also think it is alright to score both teams based on same numbers, despite utility being cheaper for Ts.
Note that when calculating, a CT may carry a T molo and vice versa, I think the logos should just use whichever one matches the side you are on, and use the sum of the two types of nades.

authors: ReneRebsdorf drweissbrot

repo: drweissbrot/cs-hud

license: ISC


text:
Rule#each raise an error if the schema is extended by another one

Hello Guys,
First of all, thank you for your gems which are really good :)
Describe the bug
An error is raised when we use the Rule#each method for a key when another key, defined before the array, does not pass the schema validation :
NoMethodError: undefined method `each_with_index' for "wrong_type":String
Did you mean?  each_line

The error seem to be raised from here : https://github.com/dry-rb/dry-validation/blob/master/lib/dry/validation/rule.rb#L86
To Reproduce
require 'dry-validation'

class TestContract < Dry::Validation::Contract
  params do
    required(:something).filled(:string)
    required(:my_array).array(:hash) do
      optional(:test).filled(:string)
    end
  end

  rule(:my_array).each do

  end
end

# `something: nil` doesnt pass the schema validation
TestContract.new.(something: nil, my_array: 'wrong_type').errors.to_h

Expected behavior
It .each block or the macros should not be executed when the schema is not correct.
Your environment

Affects my production application: NO (We can bypass this problem)
Ruby version: 2.7.0
OS: MacOS

I've update the description because it was not correct.

repo: dry-rb/dry-validation


text:
Models

Description
Create Mongoose Models for

Certificates
Request
User
Sign

Create an issue and link the same

Create an issue and link the same

The branch has 7 commits. 5 commits are shown here. 2 vanished
Weird GitHub Issue. New PR at #38

The branch has 7 commits. 5 commits are shown here. 2 vanished
Weird GitHub Issue. New PR at #38

repo: dscnitrourkela/project-guava


text:
fix: use full backward hook for compatibility with torch >= 1.8.0

Port of #1927

Something not happy here. I'll investigate.

This is not worth figuring out here now that we have access to slundberg/shap. Closing.

repo: dsgibbons/shap


text:
Running tests takes a long time when a notebook is compute-intensive

Currently the way we write labs and projects is: sprinkle questions throughout the assignment for students to fill in; put a hidden test cell after each question; students run all the tests by clicking a button (or use a trick devised by Sam to run individual tests).
The issue with this is that each test cell must run the entire notebook before running its tests.  Some of our notebooks are unavoidably compute-intensive (especially the projects, which use large datasets), so each individual test set can take minutes to run.  This is very frustrating to students.  It has been a major pain point for several labs and both projects this semester.  I can't imagine troubleshooting issues related to this for the 400 less-tech-savvy students we anticipate having next semester.
I understand that there isn't an easy way to fix this, but I think it's worth redoing the way we run tests to get this right.  Here are the four things that I think are technically possible:

Have the "run OK tests" button run a single test process and then run all of the tests.  Instead of having a shell command in the notebook's OK test cells, we could just have a magic string that indicates to the test framework that certain test files are associated with that cell.
Associate with each question cell in the notebook a button that runs only the tests for that cell.
2'. Instead, the button could run only the code up to that point, which would also fix #11.
2''. Even more ideally, the button would not create a new process at all, but rather run the associated test code inside the notebook's running kernel, which would be much faster.  It would also be less confusing for students, since there would be no discrepancy between test results and their own kernel's state.  This would not populate a submission file.  We could require students to click "run OK tests" when they are done with the lab, and that would generate their final submission file as it does now.

Plan is to have ok tests run in the current environment without reloading everything.

authors: henryem papajohn

repo: dsten/notebook-ok-extension


text:
Question about penalty terms

Thank you for this awesome library!
If I set constraints e.g. monotonic decreasing to a term s() of the Linear-GAM, is the penalty on the second-order-derivate still applied? Will I have a  for the monotonic constraint and a  for the second-order-derivative penalty or just one?
The gam.summary() method gives me just []. Is this the expected behaviour? And if i want to can I do both?

You can provide as many lambdas as many penalties you provide. There is a check in the generic Term class to check that if lambda is iterable and penalties parameter is iterable, then whether they are the same or not. If not the same, it raises a valueError.  Also, for constraints, internally a strong lam is provided(1e9). You can't access this parameter from the user end, neither gam.summary() will output this value.

Thank you! : )

authors: kaibenning shyamcody

repo: dswah/pyGAM


text:
Short backtrace

I have large codebase which uses anyhow::{Result, Context, bail} a lot,
and the errors don't tell much. No filename/line numbers at all.
Using RUST_BACKTRACE=1 is not convenient.
I found https://github.com/dtolnay/anyhow/issues/22 but it will require many changes to add it everywhere.
Is there an elegant way to get short backtrace when error occur, just like we get it with unwrap()?
Example:
use anyhow::{Result, bail};

fn main() -> Result<()>  {
    job()
}

fn job() -> Result<()> {
    bail!("error in job")
}

cargo run
Error: error in job

Imagine large codebase with many errors coming from internal libraries... no idea where it happens.
Thanks

You can call .backtrace() on the error value to get a backtrace you can print if RUST_BACKTRACE=1 or RUST_LIB_BACKTRACE=1 is used.

it used Rust std::backtrace, so there is no direct access to frames, only std::fmt::Debug which is verbose

repo: dtolnay/anyhow


text:
Extensible "builtin" types for adding custom type interfaces

As far as I can tell, the only types allowed to cross the ffi boundary by value are the builtin types or new shared types? This makes perfect sense from a safety perspective, but limits the usability of existing custom C++ ADTs across the boundary.
Would it be possible to make an extensible interface to define how new, custom C++ types should be handled? For example, some codebases have their own implementation of ref-counted pointers, which I don't currently see a good way to expose through cxx (although I may just be missing something).  It would be nice to allow users to implement their own "builtin" types, perhaps by implementing a trait defining the new type, then providing C++ and Rust interfaces to it. I'm not familiar enough with the cxx codebase (yet) to know what the interface for extensions might have to look like, but I wanted to check and see if this was worth looking into further.
If a sufficiently generic type extension interface existed, it might be useful to rewrite the current builtin types to fit this interface and thus extract their implementation from the core of the code generators?
Sorry if this has been discussed elsewhere, I looked and didn't see anything.

Extensibility has come up before in https://github.com/dtolnay/cxx/issues/16#issuecomment-577585307 but I think we're not quite in a position to tackle it yet. I agree that we want to though.
For now, two pieces of feature work that might help partially are:

#164, which would work for pointer-sized custom smart pointers.
#99, which I am currently working on; the approach in https://github.com/dtolnay/cxx/issues/99#issuecomment-621366089 gives a way to unsafely claim that a local Rust type (whether handwritten or bindgen-generated) matches the ABI of some particular C++ type and will then be able to be passed by value.

Makes sense, thanks. I might be able to take a pass at #164, as I'd like to get more familiar with the codebase, but I can't promise how soon. I'm pretty slammed with other stuff for the moment.

authors: dtolnay rinon

repo: dtolnay/cxx


text:
my iphone 10,4 (iphone 8) boots into a black screen

im attemping to dualboot 14.3 from 15.6RC, everything goes well, but it doesnt boot properly. thanks in advance
btw, the discord link is broken

iPhone 6s Plus (8,2) 15.7.3 -> 14.8 same history here - V.1.0 of script from GitHub archive is working fine

im attemping to dualboot 14.3 from 15.6RC, everything goes well, but it doesnt boot properly. thanks in advance
btw, the discord link is broken

hi thanks so much for the discord link, sorry because i add a bad option so i fixed just git pull and execute ./dualboot.sh --dualboot 14.3 --dont_createPart (putting --dont_createPart in order to just create the boot files again  ) after that your device will boot into ios 14.3

oes well, but it doesnt boot properly

did the iphone show a verbose boot the first time and after the black screen ?

iPhone 6s Plus (8,2) 15.7.3 -> 14.8 (14.2, 14.3) same history here - V.1.0 of script from GitHub archive is working fine

I fixed it, thank you for reporting it

oes well, but it doesnt boot properly

did the iphone show a verbose boot the first time and after the black screen ?

It does show a verbose boot

oes well, but it doesnt boot properly

did the iphone show a verbose boot the first time and after the black screen ?

It does show a verbose boot, then it stays on a black screen

ios 14.2 below doesnt work on iphone 8 so use 14.3 above