Parameter binding stops when a transformation attribute throws a ArgumentTransformationMetadataException

ArgumentTransformationMetadataException is supposed to represent a recoverable error, but PS does not recover.
You can use an ArgumentTransformationAttribute to help massage an object into the type expected for a particular command parameter. If the transformation fails, the docs say to "throw ArgumentException if the value of inputData is invalid, and throw ArgumentTransformationMetadataException for other recoverable errors".
However, if you throw an ArgumentTransformationMetadataException to indicate a recoverable error, PS does not recover--binding is halted. So if, for example, you have a parameter that can be bound by name to pipeline input (ValueFromPipelineByPropertyName = $true), then piping in an object with a property with the right name will not work, because the transformation will first be attempted on the object that was piped in (which will fail, as expected), and then it won't continue to look for a property on that object with the expected name.
Steps to reproduce

Add-Type -TypeDefinition @'
namespace Repro
{
    using System;
    using System.Management.Automation;
    using System.Reflection;

    /// <summary>
    ///    Useful to transform a string representation of a timezone ("Pacific Standard
    ///    Time") into an actual TimeZoneInfo object.
    /// </summary>
    [AttributeUsage( AttributeTargets.Property | AttributeTargets.Field, AllowMultiple = false )]
    public class TimeZoneTransformationAttribute : ArgumentTransformationAttribute
    {
        /// <summary>
        ///    Set this (or the other UseWorkaround_ property) to 'true' if you want the
        ///    PS runtime to be able to try other binding options (such as binding to a
        ///    pipeline value by property name).
        ///
        ///    If left as the default (false), it means the attribute will throw an
        ///    exception if it can't convert the object; else it will return the original
        ///    object for further binding.
        /// </summary>
        public bool UseWorkaround_FailGracefully { get; set; }

        /// <summary>
        ///    Set this (or the other UseWorkaround_ property) to 'true' if you want the
        ///    PS runtime to be able to try other binding options (such as binding to a
        ///    pipeline value by property name).
        ///
        ///    If left as the default (false), it means that the inner exception of the
        ///    exception that the attribute will throw if it can't convert the object will
        ///    NOT be a PSInvalidCastException.
        /// </summary>
        public bool UseWorkaround_WrapPSInvalidCastException { get; set; }

        public override object Transform( EngineIntrinsics engineIntrinsics, object inputData )
        {
            object originalObject = inputData;

            Console.WriteLine( "===============================================" );
            try
            {
                Console.WriteLine( "Welcome to the TimeZoneTransformationAttribute." );
                Console.WriteLine( "   inputData is null? {0}", inputData == null );
                if( null != inputData )
                {
                    Console.WriteLine( "   inputData type: {0}", inputData.GetType().FullName );
                    Console.WriteLine( "   inputData value: {0}", inputData );
                }

                var pso = inputData as PSObject;
                if( null != pso )
                {
                    Console.WriteLine( "getting baseobject... ({0})", pso.BaseObject.GetType().FullName );
                    inputData = pso.BaseObject;
                }

                if( inputData is TimeZoneInfo )
                {
                    Console.WriteLine( "it's already a tzi" );
                    return inputData;
                }

                string str = inputData as string;
                Exception e = null;
                if( null != str )
                {
                    try
                    {
                        var tzi = TimeZoneInfo.FindSystemTimeZoneById( str );
                        if( null != tzi )
                        {
                            Console.WriteLine( "(successfully transformed inputData: {0})", tzi );
                            return tzi;
                        }
                    }
                    catch( TimeZoneNotFoundException tznfe )
                    {
                        e = tznfe;
                    }
                }
                else
                {
                    Console.WriteLine( "it's not a string" );
                }

                if( UseWorkaround_FailGracefully )
                {
                    Console.WriteLine( "(failing gracefully by just returning the original object)" );
                    return originalObject;
                }

                Console.WriteLine( "(failing by throwing an ArgumentTransformationMetadataException)" );
                Console.WriteLine( "(which is supposed to be \"recoverable\")" );

                // BUG: Documentation indicates that this exception should indicate a
                // recoverable error; however the PS runtime does not recover by
                // continuing to attempt parameter binding once this exception is thrown,
                // UNLESS the inner exception is a PSInvalidCastException.

                throw new ArgumentTransformationMetadataException(
                    String.Format( "Could not convert '{0}' to a timezone.",
                                   inputData ),
                    UseWorkaround_WrapPSInvalidCastException ? new PSInvalidCastException() : e );
            }
            finally
            {
                Console.WriteLine( "-----------------------------------------------" );
            }
        } // end Transform()
    } // end class TimeZoneTransformationAttribute
}
'@

function Repro
{
    [CmdletBinding()]
    param( [Parameter( Mandatory = $true,
                       Position = 0,
                       ValueFromPipeline = $true,
                       ValueFromPipelineByPropertyName = $true )] # <-- BUG: will not work
           [Repro.TimeZoneTransformation()]
           [TimeZoneInfo] $TZI
         )

    process
    {
        Write-Host "$($MyInvocation.InvocationName): `$TZI is: $TZI" -Fore Cyan
    }
}

function NoRepro1
{
    [CmdletBinding()]
    param( [Parameter( Mandatory = $true,
                       Position = 0,
                       ValueFromPipeline = $true,
                       ValueFromPipelineByPropertyName = $true )]
           [Repro.TimeZoneTransformation( UseWorkaround_FailGracefully = $true )]
           [TimeZoneInfo] $TZI
         )

    process
    {
        Write-Host "$($MyInvocation.InvocationName): `$TZI is: $TZI" -Fore Green
    }
}

function NoRepro2
{
    [CmdletBinding()]
    param( [Parameter( Mandatory = $true,
                       Position = 0,
                       ValueFromPipeline = $true,
                       ValueFromPipelineByPropertyName = $true )]
           [Repro.TimeZoneTransformation( UseWorkaround_WrapPSInvalidCastException = $true )]
           [TimeZoneInfo] $TZI
         )

    process
    {
        Write-Host "$($MyInvocation.InvocationName): `$TZI is: $TZI" -Fore Green
    }
}

$customObj = [PSCustomObject] @{ TZI = "Pacific Standard Time" }

$customObj | NoRepro1
$customObj | NoRepro2
$customObj | Repro

Expected behavior
No errors should be generated by the repro script: the TZI parameter should be bound by property name in all cases.
Actual behavior
Property binding stops (so that binding by property name is not attempted) when an ArgumentTransformationMetadataException is thrown, so $customObj | Repro generates an error instead of succeeding.
===============================================
Welcome to the TimeZoneTransformationAttribute.
   inputData is null? False
   inputData type: System.Management.Automation.PSObject
   inputData value: @{TZI=Pacific Standard Time}
getting baseobject... (System.Management.Automation.PSCustomObject)
it's not a string
(failing by throwing an ArgumentTransformationMetadataException)
(which is supposed to be "recoverable")
-----------------------------------------------
Repro : Cannot process argument transformation on parameter 'TZI'. Could not convert '' to a timezone.
At C:\temp\TransformationAttrRepro\Repro.ps1:177 char:14
+ $customObj | Repro
+              ~~~~~
+ CategoryInfo          : InvalidData: (@{TZI=Pacific Standard Time}:PSObject) [Repro], ParameterBindingArgumentTransformationException
+ FullyQualifiedErrorId : ParameterArgumentTransformationError,Repro

Options to fix this
Option 1) When an ArgumentTransformationMetadataException is thrown, PS should continue to attempt binding (so that binding by property name can be tried). Currently, if the ATME wraps a PSInvalidCastException, then things work as expected. (But how would you know to do that, and why shouldn't it just work for a plain ATME?)
See the code in CmdletParameterBinderController.cs.
OR
Option 2) The first option would be a breaking change, but probably in the category of "acceptable" changes ("Any existing behavior that results in an error message generally may be changed to provide new functionality."). However, if for some reason we don't want to do that, the documentation should be updated to instruct how to properly fail a transformation without halting binding. The repro script above demonstrates two different approaches for coaxing parameter binding into continuing.
Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.1.0-preview.4
PSEdition                      Core
GitCommitId                    6.1.0-preview.4
OS                             Microsoft Windows 10.0.17713
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

@jazzdelightsme Look ArgumentToEncodingTransformationAttribute implementation in the repo.
https://github.com/PowerShell/PowerShell/blob/c1c5344a8897262433141ecbc13bb06ac2c4bbef/src/System.Management.Automation/utils/EncodingUtils.cs#L90

Sorry @iSazonov , I don't understand the relevance of that transformer. Yes, it also demonstrates the first workaround demonstrated by the repro script (UseWorkaround_FailGracefully).
Even if we decide that all the code works exactly as desired, then this is a doc bug, because you can't tell from reading the docs that it's how you should fail (docs incorrectly instruct you to throw an ATME if transformation fails, which will break further binding, which cannot possibly be what the user wanted).
(To be clear, my preferred option is to change PS to treat all ATMEs the same way that ATMEs which wrap PSInvalidExceptions are today. But even if we decide against that, something should be done; this is painful to figure out.)

@jazzdelightsme Thanks for clarify. I think the code works as expected and it is doc issue - we should add that we should throw ArgumentTransformationMetadataException with inner PSInvalidCastException exception. (Sample code in ArgumentTypeConverterAttribute). Please open new issue in PowerShell-Docs repo if you agree.


Wrong bind for ButtonPress

Nicely done i like this tooltip !!!
ButtonPress goes to mouse btn3.
Change to ButtonPress-1 and mouse btn1/left click works fine.
def _init_bindings(self) -> list[Binding]:
"""Initialize the bindings."""
bindings = [
Binding(self.widget, "", self.on_enter),
Binding(self.widget, "", self.on_leave),
Binding(self.widget, "", self.on_leave),
]
if self.follow:
bindings.append(
Binding(self.widget, "", self._update_tooltip_coords)
)
return bindings

I'm pretty sure this is the expected behaviour. It's meant to hide the tooltip whenever a user interacts with a widget.

Hi there. yes you are correct about that. It is meant to hide the tooltip.
What i meant is the default bind you have goes to button 3 on the mouse
which is right click.
I dont think right click is correct i think it should be the normal left
click so when you click somewhere else it will hide the tooltip.
Regards Greg
On Tue, 3 Dec 2024 at 20:27, Brian Z @.***> wrote:

I'm pretty sure this is the expected behaviour. It's meant to hide the
tooltip whenever a user interacts with a widget.
—
Reply to this email directly, view it on GitHub
https://github.com/gnikit/tkinter-tooltip/issues/115#issuecomment-2515295443,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVYDU57LZYEJAHZM6B5ADND2DXZZVAVCNFSM6AAAAABSS7JPZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJVGI4TKNBUGM
.
You are receiving this because you authored the thread.Message ID:
@.***>


Fine tuning for evaluation

Hi!

Help me please figure out, what would be optimal batch size for evaluating nextSentencePrediction model? For performance.  Is it same as used during pre-training (128)?
If i building high performance evaluating backend on CUDA, would it be a good idea to use several threads with bert model in each, or its better to use one thread with proper batching?

Hi @Alexadar, you have to batch your examples and pad them indeed. No other way I'm afraid.

Sorry, i missed your post request for example.
Yes, padding is only way to batch. It is slower than process sentencess one by one, i tested.


Enable and fix linting in .jsx files

Updated, I have addressed all comments thus far.

Still running into issues in the test suite selecting from the test menu on the side.

Test suite bugs seemed to be fixed. Getting proptype errors in the console but otherwise everything seems to at least be working


Updated ArmCompute to 2021.2

Could you please upgrade year to 2021 in third-party-programs.txt?

updated

PR could be merged as soon as ARM plugin build is excluded from yocto build: CVS-51429


Begin PAL'ing out S.N.Sockets.

PAL out all synchronous methods for Sockets

ioctl is an open issue

PAL out the APM methods for Sockets
Implement the synchronous and APM PALs for Linux

Some things are still a bit messy: e.g. there are some shims in place to deal with the fact that we're still building some of the Windows bits on Linux.

@CIPop PTAL

FYI: I've pushed new commits that add support for most of the Socket.*Async APIs.

Can't review src/System.Net.Sockets/src/System/Net/Sockets/Socket.cs - GitHub is saying:
125 additions, 2,769 deletions not shown
Comment on Socket.cs: Shouldn't Socket.Windows/Unix be part of SocketPal?

Socket.cs:5361 AcceptEx is marked as internal. This creates a circular dependency between Socket (common xplat) and SocketPal.
A better design would limit the dependency within SocketPal. This probably means that Socket::AcceptEx should be moved within SocketPal.

Socket.cs:5361 AcceptEx is marked as internal. This creates a circular dependency between Socket (common xplat) and SocketPal.
A better design would limit the dependency within SocketPal. This probably means that Socket::AcceptEx should be moved within SocketPal.
Same with DisconnectEx just that it takes a dependency on the particular implementation for SocketAsyncEventArgs.Windows.cs.

Yes, I agree. I did not want to move this code around quite yet, but I'm happy to do so now if you think that it's OK.

Socket.cs:5361 AcceptEx is marked as internal. This creates a circular dependency between Socket (common xplat) and SocketPal.
A better design would limit the dependency within SocketPal. This probably means that Socket::AcceptEx should be moved within SocketPal.
Same with DisconnectEx just that it takes a dependency on the particular implementation for SocketAsyncEventArgs.Windows.cs.

Yes, I agree. I did not want to move this code around quite yet, but I'm happy to do so now if you think that it's OK.

I think we should clearly separate the public interfaces from inner implementation details.
For that, we could decide on always creating a separate class which holds most of the state and separate PAL partial class implementations for various OS flavors:

Socket.cs (public interface, has no or little state) uses

SocketPAL.cs (common PAL layer, holds most state, no references to public Socket.cs APIs)

SocketPAL.Windows.cs (specific OS implementation)
SocketPAL.Linux.cs
SocketPAL.OSX.cs

SocketAsyncEvent.cs (public interface, Socket.cs can reference this but none of the PAL classes can reference back to it)

SocketAsyncEventPAL.cs (common PAL layer) can be referenced by SocketPAL.cs directly

SocketAsyncEventPAL.Windows.cs
etc

I think we should clearly separate the public interfaces from inner implementation details.

I'm not sure how that's not achieved here. The public interfaces are in Socket.cs, SocketAsyncEventArgs.cs, etc. The OS-specific files contain OS-specific implementation details only.

Socket.cs (public interface, has no or little state) uses

Unfortunately, "has no or little state" is not achievable: Socket and its related types have a fair bit of state that is relevant to the proper operation of the APIs no matter what platform we're running on.

I'm not sure how that's not achieved here. The public interfaces are in Socket.cs, SocketAsyncEventArgs.cs, etc. The OS-specific files contain OS-specific implementation details only.

It is achieved but in two different ways: one via the SocketPAL class and one via having Socket itself be a partial class.

Unfortunately, "has no or little state" is not achievable:  Socket  and its related types have a fair bit of state that is relevant to the proper operation of the APIs no matter what platform we're running on.

Why not keep Socket.cs as a public interface (we could have no state at all, just a simple pass-through to the SocketPAL class).
This means copy/pasting everything in SocketPAL and leaving Socket.cs to simply call into SocketPAL for each function. This interface separation is a recurring pattern: we're using it when designing COM/WRL classes.
The only downside is that Socket.cs will have an additional function call for each API after validating user input. The perf impact is really nothing compared to the benefit of code clarity during later support (and in most modern compilers these calls should actually be optimized in-line anyway).
Example:
Socket.cs:
       public void Connect(EndPoint remoteEP)
       {
            if (remoteEP == null)
            {
                throw new ArgumentNullException("remoteEP");
            }

            SocketPal.Connect(remoteEP);
        }

An example for a property that already does this is Socket::OSSupportsIPv4. We should move InitializeSockets() to SocketPal and leave the implementation as:
        public static bool OSSupportsIPv4
        {
            get
            {
                return SocketPal.OSSupportsIPv4;
            }
        }

This means copy/pasting everything in SocketPAL and leaving Socket.cs to simply call into SocketPAL for each function. This interface separation is a recurring pattern: we're using it when designing COM/WRL classes.

If I understand correctly, what you're suggesting involves duplicating any code that touches internal state, even if that state is shared between platforms. I don't think that this pattern is a good fit for Sockets: there is a sizable amount of state and behavior that can and should be shared between the various platforms in order to better ensure that they produce mutually compatible behavior.
In general, I see a number of options in this scenario (i.e. a type that has non-trivial amounts of both platform-independent and platform-dependent state and behavior):

Use a partial class to share platform-independent code with platform-specific code. This option is simple and expedient, but may over-expose the platform-independent details to the platform-specific code. In this case, I felt that the simplicity and expediency outweighed the downsides.
Push the platform-specific state into derived types. This option does not apply to sockets b/c the types involved are public and unsealed.
Push the platform-specific state into new value types that expose an internal API. The platform-independent types then keep a value of the platform-specific type in a field and expose state as necessary via the internal API. This option is more complicated than (1), but has the benefit of preventing over-exposure of platform-independent details.
Expose the platform-independent state as internal APIs/fields and push the platform-specific state into new types that consume these fields. This option is of similar complexity to (3), but grossly over-exposes the platform-independent details.

Long-term, I think that the most palatable option is probably (3). It should be fairly straightforward to migrate to such a design from where we are now.
FWIW, the reason that we haven't yet hit these design issues is that the other PALs that I've added are for the most part stateless, and as such can be implemented as a static class that exports an internal API.

@stephentoub would you mind taking a look at this as well?

Thanks for explaining!
The reasoning behind by initial comment is a code smell: In my mind, if it's not marked as PAL it shouldn't be a partial class and shouldn't have .Linux and .Windows versions. (It's the common part.)

Long-term, I think that the most palatable option is probably (3). It should be fairly straightforward to migrate to such a design from where we are now.

I agree that this is the right solution. (Sounds like the strategy pattern.) My solution would have only solved my concern regarding code organization but not the real issue which is better separation of internal state (context) used by different OS-specific implementation (strategies).
Do you think we could achieve this implementation now rather than after it got pulled in corefx?

Do you think we could achieve this implementation now rather than after it got pulled in corefx?

We can probably get to this before merging into corefx/master, yes. I'm going to leave it as-is for this PR, however.

@CIPop should I just go ahead and merge this to unblock #12 and file an issue to follow-up on the CR process?

Yes, I think it's easier to get this code in as-is for now and have a smaller PR for the items discussed here.

Excellent progress, Pat. Thanks.


PPO2:Total reward keep declining over time

When training my model with PPO2 in my environment,  my policy my mean total reward(sum reward from episode with gamma) keep declining over time. I can't really figure out how to let it grow.
my reward is between -12 and 6
using 5 layers fc
batch size 300 from 10 independent environments， each episode 6000 step
Could it be that I need to run the algorithm for a longer time before the total reward starts growing?

Hi @falsemail!
Could you provide more details? Is that one of the gym environments or your custom environment? What's that observation / action space size ? Batch size 300 from 10 independent environments - does that mean 300 per environment (so total 3000), or 30 per environment? How long do you train it for (total number of timesteps)? Do the average returns grow at all in the beginning (in the beginning, policy behaves pretty much randomly; so after training does it behave better or worse than random)?
If the action space is continuous (Box), what's the range?

Hi @falsemail!
Could you provide more details? Is that one of the gym environments or your custom environment? What's that observation / action space size ? Batch size 300 from 10 independent environments - does that mean 300 per environment (so total 3000), or 30 per environment? How long do you train it for (total number of timesteps)? Do the average returns grow at all in the beginning (in the beginning, policy behaves pretty much randomly; so after training does it behave better or worse than random)?
If the action space is continuous (Box), what's the range?

Thanks very much. I have find the reason which because of a bug in my custom environment.


Get BC Gov favicon

We are currently using the default Vue icons, but should be using BC Gov ones.
@CharlesMacpherson -- same as previous. Should be with Dwayne to resolve, but I don't know his GitHub handle. Please help if you know how or pass this issue to Some One Else.
Thanks

This is from Dwayne. For test

This should have what you need: https://github.com/bcgov/sbc-auth/tree/main/auth-web/public/img/icons

@amanji, @wadeking98 had submitted this PR; https://github.com/bcgov/orgbook-bc-client-vue/pull/66
It had most of the icons, but is missing some of the apple-touch ones.  The link @DJ-Gordon supplied above has a more complete set of icons.  Could you please update the icons with the set from the link please.


[WIP] TypeScript Code generation

This is a work in progress targeting TS type annotation generation. For now, only basic structures will be generated.

I think it will be easier to see what it generates with some tests!

@stubailo I intend to write a lot of them, I'm just starting on this one. I just opened the PR in case you want to provide some early feedback.

Yeah, my main interest would be to see some example TS code generated from this approach, and one way would have been to look at some tests! But I can wait :]

Yeah, I think for the iOS generation we took a different approach which was to design the generated result first, then implement the generation. But either way is fine!

@stubailo I'm trying to restart with the implementation structure for swift actually. What helps is that I clearly know what I want to get but I should formalize it indeed. I'll try to do that before continuing.

@stubailo found a basic query passing with the generator I currently have 😉 : https://github.com/apollostack/apollo-codegen/blob/a9ef9c1d1b351701426209edb17d215848194cb8/test/typescript/codeGeneration.js#L62:L79

and ... actually writing it in a test makes me realize it's not valid TS 😉. Thank you very much for the advice! Will continue on TDD now, I usually do that but I don't know why, I did it freestyle this time!

@rricard: Seems like you're on a roll! Let me know if you have any questions about the codebase, or if anything needs to change about the compiler IR output.

here is what I'll have for today: https://github.com/apollostack/apollo-codegen/blob/8bda617e7b69ffecfc2cf716cba7247260f7a958/test/typescript/codeGeneration.js

@martijnwalraven seems good for now, I'll definitely need to refactor at some point, the swift code structure was a good start but TS doesn't need that much stuff (I'm just generating type annotations) so I'll try to see how to make things lighter ... But, yea, the generator is definitely a good idea, especially for indents and blocks!

Good to hear! I'll probably try to split up the Swift codeGeneration.js at some point as well, because it is indeed getting a little too heavy.

Fearing to do the same in TS...

@stubailo would love some feedback on what I'm generating (see tests 🎉 !). Once you feel it's what we would expect from this generator, I'll refactor it!

I need to test that against the kind of complex queries I have in my app and see if that doesn't break (we have TONS of fragments!)

Ok, just tested excepted small edge cases, I think this works pretty well!
Here is what I see that is left to cover:

[ ] Nullable arrays of nullable elements (for now, doing something ugly such as: Item | null[] | null, should do: (Item | null)[] | null)
[ ] Input object fields (check if they work correctly)

@jbaxleyiii take a look at this as well, it could be a good base for your Flow Type generator!

@stubailo & @jbaxleyiii I actually need a flow generator as well and I plan to make this one run either in flow or ts mode once I hit the next PR 😉 . Since both syntaxes are similar, I think we could exploit the same thing to generate them!

One question I have is whether or not null will be explicitly sent back from the server. If not, the conditional property operator may be better.

@pspeter3 usually I see that the server sends a null back, that's how the graphql execution engine works in the spec at least

@pspeter3 btw, if you want to work on tests, you should fork the repo and derive your own branch from this one (basically, you will end up doing a PR into this PR :wink:), that way, I'll be able to see through the diff more easily and guide you more easily!

Here is a list I rapidly put together of what's left to do:

more tests on working features (take examples from the swift tests)
tests on non-working features (you will have to figure out the syntax we want - so don't hesitate to ask me, either here or on slack - my username is @rricard)
I may work on making those tests pass but if you find yourself a lot of time to contribute, you can do it as well!

Any question: ping me here or on slack. Just keep in mind that I'm in Europe so, well, I may sleep while you are working!

I have my own fork already and was planning to do the PR of a PR. Also one question, why decided to do type aliases over interfaces? Was it to intersect fragments? My belief was that type aliases don't show up in compilation errors so we may have a better developer experience if we use interfaces.

@pspeter3 most of my decisions are based on doing something similar to flow (I am using that primarily, but I wanted to do TS first to see later how much I could centralize under the same syntax actually). So, in the test, do what you feel is the more logical for TS and I'll figure out how to make that common with flow and TS later. My first objective will be to make your tests pass. So, please write some idiomatic TS, and I'll work around that!

That's actually great to have you give your input on this. I think we could end up with a better implementation in the end!

Tried some use cases for the generator, it looks good, but there are some issues I noticed:

When using custom inline fragment on an object that of type List (defined as [MyObject]) in the scheme definition, the generated type does not handle the fragment as array.
This is a unit test that fails, to demonstrate the issue:

    it(`should generate correct list with custom fragment`, function() {
      const context = this.compileFromSource(`
        fragment Friend on Character {
          name
        }

        query HeroAndFriendsNames($episode: Episode) {
          hero(episode: $episode) {
            name
            friends {
              ...Friend
            }
          }
        }
      `);

      const source = generateSource(context);

      expect(source).to.include(stripIndent`
        //  This file was automatically generated and should not be edited.

        // The episodes in the Star Wars trilogy
        export type Episode =
          "NEWHOPE" | // Star Wars Episode IV: A New Hope, released in 1977.
          "EMPIRE" | // Star Wars Episode V: The Empire Strikes Back, released in 1980.
          "JEDI"; // Star Wars Episode VI: Return of the Jedi, released in 1983.

        export interface HeroAndFriendsNamesQueryVariables {
          episode: Episode | null;
        }

        export interface HeroAndFriendsNamesQuery {
          hero: {
            name: string,
            friends: Array<FriendFragment>,
          } | null;
        }

        export interface FriendFragment {
          name: string;
        }
      `);
    });

@dotansimha that's exactly the kind of feedback I needed! thanks! I'm back working on this this week! 😉

Found a solution, need to replace the following line:
https://github.com/apollostack/apollo-codegen/blob/e32dd8983ec8733f76c7843ea66c26f8ba1ecc69/src/typescript/language.js#L38

to:
    generator.printOnNewline(`${propertyName}: ${isArray ? 'Array<' : ''}${fragmentSpreads.map(n => `${n}Fragment`).join(' & ')}${isArray ? '>' : ''}`);

Will create a PR into this PR in a few minutes.
@rricard , any chance to add a TODO list or a list of known issues to this PR? :)

@dotansimha Nice! Please add a test for your case if you write a PR. I don't have any TODO right now but you are right it would be useful, I'll start by doing that this afternoon!

Okay nice, let's finish this PR then! Just going to eat something and I'm back at work!

Also noticed that the generator changed the name of the fields (and it should not do it in any case - it's fine for the name of the operation or interface, but not for the field name).
For example, a field named full_name will generate a type with a field called fullName.

Also, @rricard , the concept of generating one big interface is a mistake.
The actual usage will be something like:
    this.subscriptionSub = this.apollo.subscribe({
      query: subscriptionQuery,
      variables: {repoFullName: repoName},
    }).subscribe({
      next: (data: OnCommentAddedSubscription) => {
        const newComment: Comment = data.commentAdded;
        // ... more code ...
      }
    });

OnCommentAddedSubscription is generated, and looks like that:
export interface OnCommentAddedSubscription {
  commentAdded: {
    id: number,
    postedBy: {
      login: string,
      html_url: string,
    },
    createdAt: number,
    content: string,
  } | null;
}

The problem is that newComment it still remains as any because we can't use the inner type of OnCommentAddedSubscription as interface, the actual generated should looks like that:
export interface OnCommentAddedSubscriptionCommentAdded {
{
    id: number,
    postedBy: {
      login: string,
      html_url: string,
    },
    createdAt: number,
    content: string,
  }
}

export interface OnCommentAddedSubscription {
  commentAdded: OnCommentAddedSubscriptionCommentAdded | null;
}

So when you want to use an inner type in your code - it's an easy usage.
The level of generated code can depend on the implementation, but the first level must get it's own interface so you will be able to extract inner types from the GraphQL response.

@dotansimha I prefer the module notation. For now, I don't think we should change this. I want to ship that as fast as possible and actually derivate this implementation for Flow ASAP (which in its current state won't take much time).
In your example, I don't see the issue though, just let TS infer your type right? Or did I spend too much time with Flow and its inference engine that I think it's a completely normal thing?
Anyway, I see the point of what you want to do, maybe just let's do that on the next iteration for TS support!

I think a "first version" is quite ready now, thanks to you (for handling those edge cases that I missed), I'll let @stubailo or @martijnwalraven give there feedback and then, let's get this merged.
Thanks for your help, ping me on slack to discuss what's next on this (same as on github: @rricard)!

@dotansimha ping me on slack if you see anything else that seems important to you!
I'll work on refactoring that PR a bit once we agree it covers a "minimal" TS support...

TS with WebStorm does not auto complete if you don't declare the type, so when using an inner property of an object - you must specify it's type, otherwise it treated as any and the auto-complete for fields does not work :(

Humm, well, I'll see what I can do during the refactor then, do you see anything else we missed before I start?

In general, we should prefer namespace over module.

Okay, I added input object types. I will followup tomorrow with a proper refactor!

@martijnwalraven & @stubailo maybe we should merge that now, the feature is properly isolated and this would allow the following:

other community contributors will be able to propose PRs against master
I'll be able to start the flow implementation (and refactor things while doing it)
I think that proposing the feature to try as early as possible would help us spot bugs or things wanted by the users more easily

(in fact starting with flow ASAP may be beneficial since it would push me faster towards refactor)

@rricard: Happy to merge this, looks great!

Wow, excited to see so much progress today on this!

@stubailo you can thank @dotansimha that spotted things I couldn't think of! Hope he'll stay around to help us get a better TS support!

@rricard: I think it would be great if you could write an article about this for the Apollo blog!

@martijnwalraven Good idea! I need to setup a sample project first though to be able to try out things correctly!

+1

@martijnwalraven can we have a release on npm with typescript support so I can use it in a sample repo? Thanks!

@rricard: Just published apollo-codegen 0.9.5 on npm

@martijnwalraven :+1: eating something and then I'm back on it!


Socket is not bound

Hi.
Sometimes can get time from servers, but most of time return this error: Socket is not bound
I test lots of port instead of 0 but result is same!

Can you post the NTP servers and ports you're trying to use?

The problem is that we are trying to use the send function not using the bind callback or the listening event: I fixed that in my fork: https://github.com/luneo7/react-native-ntp-sync/blob/master/src/client.ts#L88

The problem is that we are trying to use the send function not using the bind callback or the listening event: I fixed that in my fork: https://github.com/luneo7/react-native-ntp-sync/blob/master/src/client.ts#L88

Thanks a lot for your reply.
I want to use your fork with this command: npm install luneo7/react-native-ntp-sync
but in bundle, I have this error:
However, this package itself specifies a main module field that could not be resolved<EMAIL_ADDRESS>Indeed, none of these files exist:

Can you post the NTP servers and ports you're trying to use?

this.ntpServers = [
{ server: "time.cloudflare.com", port: 123 },
{ server: "time.google.com", port: 123 },
{ server: "0.pool.ntp.org", port: 123 },
{ server: "1.pool.ntp.org", port: 123 },
];
These are the ones used by the library itself

The problem is that we are trying to use the send function not using the bind callback or the listening event: I fixed that in my fork: https://github.com/luneo7/react-native-ntp-sync/blob/master/src/client.ts#L88

I changed the code like you and my problem was solved.
Thank you

The problem is that we are trying to use the send function not using the bind callback or the listening event: I fixed that in my fork: https://github.com/luneo7/react-native-ntp-sync/blob/master/src/client.ts#L88

Thanks a lot for your reply.
I want to use your fork with this command: npm install luneo7/react-native-ntp-sync
but in bundle, I have this error:
However, this package itself specifies a main module field that could not be resolved<EMAIL_ADDRESS>Indeed, none of these files exist:

Can you post the full error? this is not happening for me =/

The problem is that we are trying to use the send function not using the bind callback or the listening event: I fixed that in my fork: https://github.com/luneo7/react-native-ntp-sync/blob/master/src/client.ts#L88

I changed the code like you and my problem was solved.
Thank you

Merged your pull request .


[TASK]: Generate denoised ECG image from Waveform data

See if it's possible to generate denoised ECG png files directly from WFDB file pairs. This will benefit us in data transformation testing process.

It's possible to do so. Also you can add distortions and apply different colors on grid.


load more option in accordion

hi, is there any option to paginate list i mean i have 10000 records in my list . so i use pagination from server but i want when the user go to last the new list render in array ?
like in flatlist there is prop which is onReached . so is there any prop in this library ?

I'm not understanding you're use case. Accordion is just for toggling displaying of different sections.

so i there any way to use flatlist in accordion component?

You have to handle the content inside the Accordion yourself. Are you saying you have 10,000 sections?

Closing as inactive. Feel free to message or create a new issue if this is still a concern.

Is there a way to handle onEndReached something like FlatList prop? If you can add onEndReached, then pagination can be handled by updating the sections data.

is there pagination in accordion?

is there pagination in accordion?

Yeah, is there a way to paginate the accordion, like onEndReached attribute in the Flatlist ?

Found any ?


<> causes "Error in macro <>"

If you try: <<following pmario>> at your space, it may create Error in macro <<view>> if I follow someone, that you don't.
The following macro creates a  [x]-"delete this tiddler" button. But if there is no tiddler it creates the error message. It should do nothing.

This is an error in the following space. I've disabled the delete button there to remove the error.


Fonts improvement suggestions

Set a proper range for the Lato font entry, like this (Lato seems to support almost all characters within that range)
Before:

After (it may be hard to see the difference, as Verdana is very similar to Lato):

Replace some SourceScheme and ChatScheme fonts with Lato versions:

UiBold and DefaultLarge (don't seem to mess anything up)
DefaultVerySmall, DefaultSmall, Default (used everywhere, so unexpected problems can probably occur)
ConsoleText (I've heard from Hypnotize that it's better not to touch this one, because some ETF2L tool is (or at least used to be) only able to process information from user screenshots if the default font is used)
ChatFont (haven't noticed any problems, but not sure)

If you're interested, I'll provide screenshots of where each is used (at least to my knowledge). Personally, I replaced all of the above fonts with Lato versions and I'm more than happy now :)

Somehow improve the visibility of the font used by HudHintDisplay, since it looks kinda ugly even at 1080p. However, I have no idea what exact font definition is used there.

I implemented a majority of those, I could probably add the achievement ones as well. In the past, I did actually change a few of those (such as chat font) to Lato but switched them back to default for one reason or another (might have been people complaining about it).
Regarding the jump timer, I think that's controlled by HudHintText in clientscheme. The actual element is HudHintKeyDisplay, and it's also animated to some extent. I vaguely remember trying to fix the appearance of it through animations, but I can't recall where I ended up with that. Its color is set by FgColor in clientscheme.res as well

Agreed, it does look better that way. I'll also add it in for the next set of commits

Interesting, it probably has to do with the way sourcescheme and sourceschemebase get squished together

Interesting, I wonder why Google Fonts doesn't list Russian in its glyphs whereas Adobe does.
Ah, okay so it looks like Google Fonts is Lato 1.0, whereas Adobe Typekit is Lato 2.0 (3000+ glyphs). I think at some point (probably when I was doing the bot character font modifications) I downloaded the latest Lato..probably from his website. In any case, I think I have a better idea of which languages are actually supported by Lato now.

@qkeitoe It sounds like I'd be needing to add this 0x0021 0x0513 range for anything using Lato, if I'm understanding right? And that ranges seems to cover Basic Latin, Latin-1 Supplement, Cyrillic and Cyrillic Supplement.
If I wanted to cover all the languages that Lato supports, I think the ranges would be:
0x0020–0x052F (Basic Latin, Latin Extended, Greek, Cyrillic)
0x2E80–0x9FFF (Chinese)
0xFE30–0xFE4F (CJK Compatibility)
0x2000–0x206F (Punctuation)
..the issue is that I'm not sure if you can list multiple ranges. I'm not sure where documentation exists for this. Maybe you can just list multiple range lines? I need to figure out how to test that 🤔

Btw, regarding 1d5960f, I believe it's a good idea to do the same for ChatScheme and SourceScheme as well.

..strange, I never realized I didn't have CustomFontFiles defined for those. I suppose I didn't have Lato used before, though

@qkeitoe Now that I think about it, I may have never changed the console font because Lato isn't monospaced:

No worries, it is your own take on the hud so you're free to do whatever you please with it :D. I do want to like Lato in the console, but the lack of monospacing is just really throwing me off unfortunately..

I just forgot tbh, I need to add those ones in too

Here's the achievement text updated:
before

after


Focus state issues with breadcrumbs using slotted links in React

Summary of the bug
When using slotted links in breadcrumbs, the current page is focusable and briefly shows the native focus indicator. In Safari, it shows a black underline.
🪜 How to reproduce

Go to the Slotted links or React Router story in the React Storybook.
Tab through the links.
See the following:

The breadcrumb for the current page is focusable in both Chrome and Safari.
The current page breadcrumb shows an outline around it briefly when it is focussed, and it shows a black underline on Safari.
On Safari, it also moves a bit when you tab off it.
If you focus on the current page, and press Enter, it actually works as a link, taking you to that page (technically refreshing the current page you are on).
On Safari, when tabbing through or hovering on the breadcrumbs, the underline disappears.

📸 Screenshots or code
On Chrome:
https://github.com/user-attachments/assets/57eb90a8-8bc2-486e-8e97-ad4a612bf478
On Safari:
https://github.com/user-attachments/assets/1c252794-c8a0-40b1-8fdd-4b2cf2e972b0
🖥 📱 Device

Browser: Chrome and Safari

🧐 Expected behaviour
The current page should not be focusable at all as you are already on that page (see the breadcrumbs which don't have slotted links).
📝 Acceptance Criteria
Given that there are breadcrumbs on the screen which are using slotted links
When I tab through the breadcrumbs
Then the current page breadcrumb should not be focusable at all.

Related to #2196


Alter OncePerSparkSession to be instantiatable even without provided SparkSession

Background
Currently OnlyOncePerSparkSession can be instantiated only when provided with SparkSession. This turns out to be limiting for classes that needs to be created before Spark is available.
Feature

add a new constructor which takes no parameters
keep the old constructor, including autoegistering step
make register method public, while keeping the feature that actual registration happens only once per SparkSession

Up to consideration if to make the SparkSession parameter of the old constructor explicit, to avoid confusion when the (auto-) registration happened and when not.
On the other hand that would create a breaking change for all current users.

Bonus
Please change the signature of the method register to return True if the actual registration happened or False if it has happened in an earlier call.
(I think it's such a small change, no point creating a dedicated ticket to it)


Allow @ to be used as a divider with cli: install and info.

@ is replaced with # as part of the info and install commands.

is the appveyer branch test working? it has not reported on the last 4-5 PRs Waiting for status to be reported

I'm not sure. I've reset appveyor authentication, maybe it'll work next time.
For now I've merged manually. Great work! :)

Awesome, send another my way please.

@wookoouk Could you maybe handle https://github.com/bower/bower/pull/2263 ? We need to make sure bower won't hang for old git versions (that don't support GIT_TERMINAL_PROMPT)

(it's the only task that blocks next release)

On it

I have confirmed version 1.8.0 does not allow for installing from a git URL.  downgrading to 1.7.9 resolves this problem.


Crash after eating crystal apple

It seams a conflict with "supersaturation" mod.
crash-2024-05-22_00.01.41-server.txt

Thanks, Will look into this a hopefully get a fix into the next version

This is an issue with supersaturation, I made a PR to their mod, if they merge it in it should fix the issue. I also added a change in the Crystal Apple so it won't crash anymore, but supersaturation won't work correctly with it.

Workaround available in 1.20.1-1.6.1. Fix will be on supersaturation's side.