The Draft Type-system is Too Anemic.

I was reading the draft for the type-system (XDN03) and it looks simultaneously too much and too little — allow me to suggest that, as presented, the type-system is anemic in what might be expressed while having far too many fundamental types.
The goal of the type-system should not be about presenting familiar fundamental types (eg Int16) but rather giving an expressive type-system especially because the goal of xlang is about making cross-language APIs available to other languages and a good type-system may preclude errors. As an example, allow me to present a small section of Ada code:
   -- A Social Security Number type for use in a database; format: ###-##-####.
   Type Social_Security_Number is new String(1..11)
     with Dynamic_Predicate =>
       (For all Index in Social_Security_Number'Range =>
          (case Index is
             when 4 | 7  => Social_Security_Number(Index) = '-',
             when others => Social_Security_Number(Index) in '0'..'9'
          )
       );

The above declares a string-type which exactly conforms to the format of a social security number and thus does not require constant checking within the body of a function, not only does this formulation reduce the need for run-time checking and code-duplication, it also can be used to endure correctness of stored data [eg in the database].
Moreover, a more robust type-system could reduce the number of fundamental types needed; consider the effect the ability of parameterizing types can have — which has some overlap with #216 — the following psudeocode shows how all the signed/unsigned integers in the draft's fundamental-types could be reduced:
Type Generic_Signed_Integer(Bits : Positive) is range -2**(Bits-1)..2**(Bits-1)-1
     with Size => Bits;
Type Generic_Unsigned_Integer(Bits : Positive) is range 0..2**Bits-1
     with Size => Bits;

then the above could be used in a package/module containing
   Type Int8   is new Generic_Signed_Integer( 8);
   Type Int16  is new Generic_Signed_Integer(16);
   -- …
   Type UInt8  is new Generic_Unsigned_Integer( 8);
   Type UInt16 is new Generic_Unsigned_Integer(16);
   -- …

Not only would such paramaterization be extraordinarily useful for constructing generic types, reducing the need for more code [and introducing more chances for cut-and-paste style errors], but the facility could be used to increase safety as well. The following Ada construct, for example, would have completely precluded the possibility of the Heartbleed bug:
   -- The Message type takes the Length parameter and binds its value to the
   -- String's length, precluding the length/data mismatch; the default of
   -- filling the Text field's value with the space-character precludes the
   -- leakage that would be caused by using uninitialized memory.
   Type Message(Length : Natural) is record        -- Length 0 is an empty string.
      Text : String(1..Length) := (Others => ' '); -- Space-filled default.
   end record;

The fundamental String type in the proposal is, in a word, bad. Restricting strings to UTF16 is shortsighted and severely cripples the usefulness of the entire project, precluding libraries which use 8-bit character-sets or the usage of the full UTF32; if you're willing to allow types themselves as parameters to other types rather than mere values, you could say something like:
 Type Generic_String( Character : Type ) is Array(Positive range <>) of Character;
 Type UTF16 is new Generic_String( Chr_16 ); -- Assuming Chr_16 is a UTF16 codepoint.

Perhaps a look at the Interface Design Language by Wulf, Lamb, and Nestor (all of CMU) would prove instructive; there's a technical report here and a book containing the specification here (ISBN:<PHONE_NUMBER>), I would highly recommend looking at them if for nothing else than the inspiration and insight into something similar, though tangential, to xlang's purpose. — If I were to build on IDL, personally, I would update its syntax to be similar to Ada/SPARK and leverage the SPARK proof-tooling.
Lastly, allow me to suggest xlang completely steal Ada's notion of "subtype" — in Ada a type is a set of values conjoined with a set of operations, a subtype is a set (possibly null) of constraints upon the values of the [sub]type from which it is derived [which is equivalent to making a subset of the given values], thus you can say:
   -- A 32-bit integer.
   Type Integer is range -2**31..2**31-1 with Size => 32;
   -- A non-negative 32-bit integer.
   Subtype Natural is Integer range 0..Intger'Last;
   -- A positive 32-bit integer.
   Subtype Positive is Natural range Natural'Succ(Natural'First)..Natural'Last;

Perhaps some explanations of the above are needed. In Ada types have attributes (see also LRM — 4.1.4 Attributes), which can be queried to retrieve properties of the type. In the above the attribute First corresponds to the first value in the type, and likewise the Last attribute corresponds to the last element; the Succ(X) attribute returns the next element (after X) in the set of values and is thus equivalent to X+1 for integer types, thus the above are saying "Natural is an Integer within [0..<last integer value>]" and "Positive is a Natural within [1..<last natural value>]", respectively. — This addition of constraints is incredibly useful for both reasoning as well as ensuring correctness, including this functionality in the xlang type-system would be very good for increasing the usability, especially with respect to such technologies as theorem-proovers.

Note that we are not trying to define an entirely new all-encompassing type system. Rather we are defining a type system that can be expressed in a natural and familiar way in various programming languages.
One of our conceptual tests prior to adding a new construct to the type system is how that construct could be expressed in various languages, such a JavaScript, C++, C#, Go, Rust, etc.
The problem with leaning towards a more expressive type system is that it starts expressing type system constructs / constraints that are lost when projecting that type system to a language without the necessary semantics. It's always a tradeoff. We want to avoid a least-common denominator approach but we also don't want to introduce concepts which will be discarded by many languages.
As a simple example, both WinRT and xlang have the type system concept of a 64-bit integer, both signed and unsigned. However, those semantics are unable to be preserved when projecting the type to JavaScript, which has only a Number type with 56-bit precision. This leads to interoperability issues.

@brentre One increasingly common expressive type system feature that I think you should consider is non-nullability constraints on reference types. This is becoming more and more common in both new and existing languages, for example TypeScript, Rust, Swift, and upcoming additions to C#. . When a language expects non-nullability by default, it can be awkward to interact with API surfaces that may produce null values everywhere.
I do think that to remain relevant and useful the WinRT/xlang type system should try to evolve along with trends among the languages that it works with, and I think non-nullability is an example of such a trend.

@BrentRe I am wondering about the opportunity for you to define the behavior of the cast/conversions among typed and untyped languages.
IMO it would be very useful (for everyone contributing to xlang) to provide a reccomended behavior for those transformations.
For example, when converting from the javascript number to C++, what are the guidelines in picking uint32_t, float or double? Internally nodejs/v8 makes a distinction between integers and floating point (for perf reasons). I believe xlang specs should give at least the guidelines to pick the best possible type.

@BrentRe Said:

The problem with leaning towards a more expressive type system is that it starts expressing type system constructs / constraints that are lost when projecting that type system to a language without the necessary semantics. It's always a tradeoff. We want to avoid a least-common denominator approach but we also don't want to introduce concepts which will be discarded by many languages.

Honestly, this seems completely backwards, akin to saying "we need to optimize this language for compiler=writers, rather than for the programmers using it" or "we need to optimize for the lowest common denominator: Intel's 286" — this stance/design-decision will kneecap the xlang project and render it nearly useless: after all, everybody else is going that route.

As a simple example, both WinRT and xlang have the type system concept of a 64-bit integer, both signed and unsigned. However, those semantics are unable to be preserved when projecting the type to JavaScript, which has only a Number type with 56-bit precision. This leads to interoperability issues.

The solution is simple: make the language robust, make the projector raise an exception when it cannot translate into the target/projected language — the stated purpose of xlang is for APIs, are you going to make preconditions, postconditions, and function-ordering ("A must be called before B") simply because this concept doesn't exist in many languages? Yeah, it could be a very hard problem for projecting to some languages, but there's no reason you couldn't stub that particular functionality on those projectors or raise an exception or even put in the documentation: "this advanced feature does not work in C, C++, [etc]".
@contextfree said:

I do think that to remain relevant and useful the WinRT/xlang type system should try to evolve along with trends among the languages that it works with, and I think non-nullability is an example of such a trend.

I agree, but with a caveat: xlang ought to be very high-level, able to express complicated things, even if they aren't directly translatable into the lowest common denominator language. BrentRe's reply honestly reminds me of the stupidity that is the design of WebAssembly: they're literally designing it for C++, since that's their minimal viable product, despite that this kneecaps them with regard to parallelism and a lot of optimization. (See: Guy Steele's How to Think about Parallel Programming: Not! video.)
@raffaeler said:

I am wondering about the opportunity for you to define the behavior of the cast/conversions among typed and untyped languages.

This is an excellent question, and while I'm not sure cast/conversions are a property of the type-system per se it is the case that defining them well can alleviate a lot of confusion, especially if you're operating in a multilanguage environment with languages that have very different conversion rules.

For example, when converting from the javascript number to C++, what are the guidelines in picking uint32_t, float or double? Internally nodejs/v8 makes a distinction between integers and floating point (for perf reasons). I believe xlang specs should give at least the guidelines to pick the best possible type.

This should be handles automatically by the projector... but in this particular case JavaScript numerics are mandated by ECMA-262 to be:

4.3.20 Number value
primitive value corresponding to a double-precision 64-bit binary format IEEE 754-2008 value
4.3.21 Number type
set of all possible Number values including the special “Not-a-Number” (NaN) value, positive infinity, and negative infinity

So, the answer is double, IIRC.
This illustrates my point: it would be stupid to force every projector to use the binary 64-bit IEEE-754 for a dice game because of the Javascript restriction despite most languages having a proper integer type, and some languages having ranged types like Type D6 is range 1..6;.
xlang should think in terms of the problem-space (that is representing APIs), giving tools and constructs that are robust and expressive, rather than in terms of what common/popular languages can do.

@OneWingedShark the V8 javascript execution engine internally distinguish between integers and floats even if javascript claims to only use IEEE-754 for all.
The distinction is super-important for perf reasons: using a double instead of int in a for loop would lead to very poor performance.
The conclusion is that javascript implicitly uses two different numeric types even if there is no explicit way to define them. While it is desiderable leaving the deduction to V8, as a xlang provider developer, I definitely want to get advantage from this and provide a mapping to C# not just using doubles but, at least, integers and doubles.
My request is to define a best practice to guide xlang language providers to adopt a reasonable choice when mapping types that apparently cannot be mapped.
I hope to have clarified a bit more my point.

@OneWingedShark, thanks for raising the discussion.
I don't think your suggestion is at odds with what we're trying to accomplish, but we're not there yet either. To achieve interoperability and fine grained control, we're still focused more on the ABI and basic language interoperability. They're required building blocks. When you transfer data from one type system to another you need to agree on the format and interpretation of the data. The IDL-style tooling we're building now will also be focused on that for the time being.
However, the metadata format and abstractions will allow us a lot of room to grow. Trying to achieve that level of type system expression in the languages that we're currently targeting would greatly slow our ability to get to V1 (and given that Windows ships thousands of APIs using a very type system, it's obviously sufficient to provide a lot of value), but I think the door is still open to achieve something along the lines of what you're proposing this in future iterations, and I can certainly see the value.
It could also lead to a great set of topics around enforcement of debuggability of pre-conding, post-condition and invariant violations, which is something that WinRT is not highly consistent about (e.g. handling of non-null values). I think there's room for some innovation here in both the type system & the runtime.
Ben

@OneWingedShark, thanks for raising the discussion.

You're quite welcome.

It could also lead to a great set of topics around enforcement of debuggability of pre-conding, post-condition and invariant violations, which is something that WinRT is not highly consistent about (e.g. handling of non-null values). I think there's room for some innovation here in both the type system & the runtime.

I very much agree, and I see a lot of potential for the underlying idea.

However, the metadata format and abstractions will allow us a lot of room to grow. Trying to achieve that level of type system expression in the languages that we're currently targeting would greatly slow our ability to get to V1 (and given that Windows ships thousands of APIs using a very type system, it's obviously sufficient to provide a lot of value), but I think the door is still open to achieve something along the lines of what you're proposing this in future iterations, and I can certainly see the value.

This is where it really hurts: these things aren't all that good as a "bolt-on". Take, for example, security: you can do a program slap-dash then come back later and do bug-fixes, refactorings, and re-engineering to patch-up all the security-holes in the initial implementation OR  you could design the program to be secure from the outset. The latter is much more likely to cost less, in the long run, but the former is deceptively alluring because you get "working" easier/quicker.
Or, if you'll allow an anecdote:
Several years back I was talking with someone on an online forum, and we were talking about tech and Ada came up. He related to me that he was part of a company that did a code-audit on Windows (2.x, IIRC; 98% sure it was pre Windows for Workgroups 3.11) he and his company noted a lot of possible errors and recommended that it be rewritten in Ada. — Now, if Microsoft had done a rewrite in Ada, there would have been several major consequences: (1) the massive amount of buffer-overflows that were notorious for awhile wouldn't have happened; (2) the OS would have been more stable, esp. if exceptions were incorporated into the process execution-type; (3) the Windows message-loop could have been vastly improved [though to be fair, the task interface that would have been best for this wasn't introduced until Ada 2005, and Smalltalk's message-passing is arguably even better, though might have been too heavy-weight/dynamic/slow at that time-period]; and (4) the recent "everything has to be rewritten for multicore!!" craze would have been trivially solvable by recompiling the source thanks to the high-level task construct.
Now I understand that there's thousands of APIs that Windows ships, this is inevitable when you have as large a code-base that's been used for so long, but how much value-added would it be if you could trivially say "parameter X cannot be null" in the source and have the projectors take care of this? — How valuable would it be to be able to, for a binding of OpenGL, be able to specify for glAccum the following?
Type Accumulator_Operators is (
	ACCUM => GL_ACCUM,	LOAD => GL_LOAD,	OP_RETURN => GL_RETURN,
	MULT => GL_MULT,		ADD => GL_ADD
    ) with Size => GL_Enum'Size; -- Where GL_* are the appropriate constants.
--...
Procedure Accumulate( Operation : Accumulator_Operators; Value : GL_Float )
  with Import, Convention => stdcall, External_Name => "glAccum",
  Pre => not Executing; -- Executing is true between calls of glBegin & glEnd.

The above eliminates in client-code GL_INVALID_ENUM and GL_INVALID_OPERATION errors, leaving only the GL_INVALID_OPERATION as a possible error. — So, just by specifying things at a higher level we can eliminate several error-classes altogether, making things both safer and more maintainable than the low-level specification.

I don't think your suggestion is at odds with what we're trying to accomplish, but we're not there yet either. To achieve interoperability and fine grained control, we're still focused more on the ABI and basic language interoperability. They're required building blocks. When you transfer data from one type system to another you need to agree on the format and interpretation of the data. The IDL-style tooling we're building now will also be focused on that for the time being.

Is the ABI that big of a concern?
Why is ABI that big of a concern?
You're asserting they're fundamental, basic to interoperability... but is it?
Isn't it true that changing compilers can destroy the binary-compatibility? Isn't it true that changing architectures can destroy the binary compatibility? (eg moving from a 32-bit compiler to a 64-bit compiler, or from x86_64 to IA64.) — Given that, it seems rather like a premature optimization to worry about ABI, and might I suggest that the problem might be addressed as parameters of the architecture fed into the projector and/or properties of the IDL-like source? What would the following be missing in terms of information needed for interoperability?
Function Pop( Object : in out Stack ) return Element
  with Convention => COBOL, External_Name => "POP-ELEMENT",
       Pre => Not Empty(Object),
       Post => Pop'Result = Element(Object'Old) and Size(Object) = Size(Object)-1;

And what about "prior art" in the field? IIRC, IBM's System Object Model was extremely good at binary-compatibility; perhaps it would be easier to obtain a license from them for that technology? Or, perhaps, OpenVMS's Common Language Environment, which IIUC is now under the care of VMS Software, Inc.

Oh wow, I see CORBA's mentioned in there too. I worked on an early attempt at a CORBA / SOAP bridge product as an intern nearly 20 years ago at a previous company. That brings back memories. There's a great book comparing other similar systems called Component Software written by Clemens Szyperski. Although a bit dated now, it's still a good overview of the problem domain.
You're hitting on a key fundamental question about the nature of this project though. xlang is, at the end of the day, a component system that happens to support many languages rather than a language interop model fist. That leads you down a path similar to COM, SOM, CORBA, etc. A comparison between SOM & xlang would be interesting. WinRT is a bit more modern of a foundation to start from in many respects, but there may be things to learn from what worked & didn't in SOM, since it starts from a very different foundation than the COM lineage. Am I correct in otherwise observing that SOM seems to be abandonware (last release in the 90s?). An example of an interop-first approach is swig. It's a robust language interop mechanism between C and pretty much everything else, but certainly does not get you a component model. They make some very different design decisions.
Binary compatibility requires some amount of common context for the compiled binaries: typically the same processor architecture and operating system. With that framing in mind, it's quite achievable, as has been proven out over time on Windows. COM has been the extensibility mechanism for many applications & services on Windows. WinRT was a great Windows-specific refresh to COM that allows a much simpler developer experience. xlang is, in some sense, the cross-plat "refresh" of WinRT. Being platform agnostic, portable, and open-source appeals to a much larger potential audience and embraces new use cases, but it also very much follows in that lineage.
I'm pretty sure if you tried you could re-write the expression above in a C / C# like syntax that could be comfortable accommodated in IDL without feeling like a bolt-on. Other languages  have done a reasonable job with even uglier syntax conventions.
Ben

Oh wow, I see CORBA's mentioned in there too. I worked on an early attempt at a CORBA / SOAP bridge product as an intern nearly 20 years ago at a previous company. That brings back memories.

Good memories?

There's a great book comparing other similar systems called Component Software written by Clemens Szyperski. Although a bit dated now, it's still a good overview of the problem domain.

Just because it's old doesn't mean that its wrong or useless though. To get on a slight tangent to prove the point, the idea of DB-backed development-environments completely solves both the diff-tool false-positive and Continuous Integration problems (and better than "modern" approaches), as detailed in this paper from 1987. — But thank you for pointing out this book, it looks interesting.

You're hitting on a key fundamental question about the nature of this project though. xlang is a component system that happens to support many languages rather than a language interop model fist.

I think I see the distinction, but would like a bit more elaboration on it.
Also, is this a valid distinction? Or, rather, should I phrase it as "Do the two necessarily have to be opposed?"
That components are needed is undisputed, but the concentration on implementation details first (eg ABI and lowest-common denominator type-system) seems backwards to me: just like if it were interop-first the primary focus should be not describing thing in [primarily] a low-level form, but in the ability to describe a wide range of things [ie high-level] foremost. — So, for a component-based system the focus should be primarily on the ability of describing components and their interactions at a high-level rather than prematurely saying (eg) "enum is 16 bits."
If you remember Delphi, there was a DFM-file which contained properties of the [visual] components which were set to non-default values — I don't remember if C# has the same sort of setup, but given Anders Hejlsberg's involvement in its design it's rather likely — and that could be considered the text-serialization of the component. If you were to take this idea and marry it to the base meta-object of the component framework, integrating/adding a serialize/deserialize pair of functions which themselves use/implement ASN.1… well, now you have a platform-independent way to load, store, distribute, and transfer components, regardless of the [eventual] ABI —— Heck, if you were to split the triggered 'actions' [eg OnClick] into three parts (1) client/pre-process, (2) server/process, & (3) client/post-process you could have the framework very naturally do client-server distributed applications; the old (and now new again) idea of having a lightweight device do the UI and light processing with all the "hard work" offloaded to your big computer.
So, it seems to me that you could do a good component-based system completely independently of things like ABI.

That [interop-first model] leads you down a path similar to COM, SOM, CORBA, etc. A comparison between SOM & xlang would be interesting.

I fully agree, it would be quite interesting; I just don't think the two are necessarily opposed — if you did the above, but also used (eg) VMS's CLR [or COM or SOM or whatever] to solve the ABI problem, wouldn't that essentially be addressing the whole thing?

WinRT is a bit more modern of a foundation to start from in many respects, but there may be things to learn from what worked & didn't in SOM, since it starts from a very different foundation than the COM lineage.

This is true, but "modern" doesn't mean a whole lot when it comes to quality of design — as an example, consider the virtual keyboard that Apple-products use: note how the J and F keys are rendered with the little touch-ridge? That ridge is on physical keyboards so that you can feel where to place your fingers, meaning that it's an absolute waste on the flat/featureless touchscreen of an ipad… and, likewise, a lot of "modern" solutions are strictly inferior to older solutions.
Perhaps a good illustration of this can be had with JSON. JSON is a terrible solution to the problem of serialization/deserialization, despite its modernity and popularity: it lacks the ability to constrain values, it lacks the ability to [automatically] validate the data received, it doesn't really support JavaScript objects (because numerics cannot be NaN or INF, but must [possibly] be in JavaScript.)
TL;DR — "Modern" is not a good indicator of quality, but the comparison between (eg) SOM & xlang would be quite interesting.

Am I correct in otherwise observing that SOM seems to be abandonware (last release in the 90s?).

It looks like it; in the [admittedly small] efforts to track it down on my part I haven't come across new/updated info… but my search-abilities aren't the greatest and IBM could certainly "pocket" or "rebrand" the tech on the downlow w/o anyone knowing.

An example of an interop-first approach is swig. It's a robust language interop mechanism between C and pretty much everything else, but certainly does not get you a component model. They make some very different design decisions.

Interesting.

Binary compatibility requires some amount of common context for the compiled binaries: typically the same processor architecture and operating system.

Sure; but with a little clever design, the engineering can mitigate this. (As shown above WRT adding cross-platform serialization via ASN.1.)

With that framing in mind, it's quite achievable, as has been proven out over time on Windows. COM has been the extensibility mechanism for many applications & services on Windows.

Granted.
Microsoft has done an amazing job WRT the backwards-compatibility of Windows. (Arguably too good, as so many of its programs are essentially forced to the x86[_64] architecture because of their historical reasons.)

WinRT was a great Windows-specific refresh to COM that allows a much simpler developer experience. xlang is, in some sense, the cross-plat "refresh" of WinRT. Being platform agnostic, portable, and open-source appeals to a much larger potential audience and embraces new use cases, but it also very much follows in that lineage.

I can see this. I still think that basing the type-system on lowest-common denominator features is a self-defeating move though.

I'm pretty sure if you tried you could re-write the expression above in a C / C# like syntax that could be comfortable accommodated in IDL without feeling like a bolt-on. Other languages  have done a reasonable job with even uglier syntax conventions.

What, exactly, does syntax have to do with anything here?
Forget, for a moment, "C/C# like" (or IDL) and consider the conceptual-space — it's about being able to specify something first and foremost, not about what the method-of-specifying looks like, right?
Secondly, what IDL? There are several. — More seriously, anyone on this project should take a look at the Wulf/Lamb/Nestor IDL (tech-report, book), which was remarkably expressive for being developed circa 1981 —link to DTIC.mil-archived development plan for DIANA (Descriptive Intermediate Attributed Notation for Ada; essentially an Attribute-grammar+IR hybrid) & STARS (Software Technology for Adaptable, Reliable Systems).


How can I use it with Laravel?

I've been reading that you have to install dependencies trough command line (I mean npm), but in the laravel structure there are many folders, so, where exactly do I have to install it?

I was thinking that it was necessary to save all mjml files in some folders and import them, but, reading with calm the documentation I realize that use this framework is a breeze. Just install it globally in the machine using npm and the just copy and paste the rendered file to destination path. Nice!

@yammadev can you please provide some info or quick help/tutorial about using Laravel with MJML ?

@fsasvari I am working on creating a package to support MJML in Laravel similar to how we currently use Markdown. I will probably release a beta tomorrow. You're welcome to test and share feedback :)

@asahasrabuddhe Great news :) Will test it in the following few days.

@asahasrabuddhe sure, in that moment it was a good solution for me, because I just wanted to compile just 1 to 2 emails at most, but in the long term, the best solution should be compiling automatically and in real time, which is what your package aims to do.

@yammadev If you can spare time, please give it a try and share your valuable feedback. Thank you!


Compatibility issue between ui-grid, ng-pattern-restrict and IE11

I've got a compatibility issue between ui-grid (https://github.com/angular-ui/ui-grid), ng-pattern-restrict and IE11.
The problem is that when trying to edit a cell, which when in edit mode is an input element with ng-pattern-restrict attached to it (using custom template), the code below will cause the cell to immediately close again.
notThrows(function () { input.setSelectionRange(0, 0); })

I've made two plunkers to make it easier to grasp the problem, here is a plunker with the problem: http://plnkr.co/edit/ZUxXAMMqRpQ1ksTUcI2u?p=preview
If you target a cell on the last row and the row isn't completely visible as illustrated on the picture below, and then try to write any number (my demo regexp only allows numbers), you'll see that the cell stutters and don't enter edit mode. If you want to see how it should look like just edit any other cell on any other row.

I have identified the problem to the code snippet pasted above, here is a plunker using a typeOf check instead, which seems to solve the problem at least for this case: http://plnkr.co/edit/4BeVS7wcTST5Swpx7yQl?p=preview
I saw that in #24 you touch this part of the code, and that change would maybe fix my issue. How is that pull request coming along?

Hi! First of all, thank you very much for this great detailed bug report. I really appreciate the effort you put into it.
On the code change, it's been pretty much stuck on webdrivers giving me hell on non-text inputs, which really impedes my ability to check browser compatibility. I've been waiting on some colleague's input on Sikuli, which may help in overcoming that, but CI integration is going to be a whole other subject.
I think the best option might be to drop some browsers off the compatibility matrix, setup a bunch of VMs (Linux, Windows, Mac) with a bunch of browsers (FF, IE, Chrome, Safari at the very least) and test it out manually. I'll see if I can setup something over the weekend and at least get these bugs out of the way.
Any ideas would be appreciated.

Thanks for quick reply!
I've seen https://saucelabs.com/home been used for CI testing cross browsers, it's free for open source projects also.

Yes, that exactly what I've been experimenting with. This is one of the tests, as an example, with the new code: https://saucelabs.com/beta/tests/798a31ea6064498db7f7c418cecda0d1

@mathiasdose Hi! The problem was effectively fixed with the changed you mentioned.
Thanks for the Plunkr, it made it really easy to verify!

@AlphaGit Awesome, thanks for the help!

@AlphaGit How long can I expect before I see the update on bower?

@mathiasdose I was expecting to wrap up some other tasks before releasing the new version. It may take a while (a few days... weeks?). These are the tasks I wanted to finish.
If you need it right now, I'd suggest you point bower to the particular hash of the latest commit right now, or to master directly if you want to get the latest whenever it is updated.

@AlphaGit Okey I'll point it to the latest commit.

@mathiasdose Sorry to bother you again, but I just released 0.2.0 with the latest changes and I thought you'd like to know. ;)


aws-sam-cli: 1.6.2 -> 1.14.0

Motivation for this change
Upstream update
Should wait after #103742
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Can you please target staging?

For anyone else who needs the latest version and is waiting on this...
In my main configuration.nix I called out to another file.
  awsSamCli = pkgs.callPackage ./aws-sam-cli.nix {};

Then swapped out the nixpkgs version of SAM CLI for my version.
  environment.systemPackages =
    [
      awsSamCli

In my aws-sam-cli.nix file, I combined the two files in this PR and updated the hashes.
{ lib, pkgs }:

(
  let awsSamTranslator = pkgs.python37Packages.buildPythonPackage rec {
    pname = "aws-sam-translator";
    version = "1.32.0";

    src = pkgs.python37Packages.fetchPypi {
      inherit pname version;
      sha256 = "1bjnkl6i6ddj6a88yapzn08qz1l03jq42mg284sp0ycva81argwc";
    };

    # Tests are not included in the PyPI package
    doCheck = false;

    propagatedBuildInputs = [
      pkgs.python37Packages.boto3
      pkgs.python37Packages.jsonschema
      pkgs.python37Packages.six
    ];

    meta = with lib; {
      homepage = "https://github.com/awslabs/serverless-application-model";
      description = "Python library to transform SAM templates into AWS CloudFormation templates";
      license = licenses.asl20;
      maintainers = with maintainers; [ andreabedini ];
    };
  };

in
  pkgs.python37Packages.buildPythonApplication rec {
    pname =  "aws-sam-cli";
    version = "1.13.1";

    src = pkgs.python37Packages.fetchPypi {
      inherit pname version;
      sha256 = "0s2bxbf3j4mlxmmcjjmfplixpp5khxxgkhd96bb1s09l1l3mc2il";
    };

    propagatedBuildInputs = [
      pkgs.python37Packages.aws-lambda-builders
      #pkgs.python37Packages.aws-sam-translator
      awsSamTranslator
      pkgs.python37Packages.chevron
      pkgs.python37Packages.click
      pkgs.python37Packages.cookiecutter
      pkgs.python37Packages.dateparser
      pkgs.python37Packages.python-dateutil
      pkgs.python37Packages.docker
      pkgs.python37Packages.flask
      pkgs.python37Packages.jmespath
      pkgs.python37Packages.requests
      pkgs.python37Packages.serverlessrepo
      pkgs.python37Packages.tomlkit
    ];

    # fix over-restrictive version bounds
    postPatch = ''
      substituteInPlace requirements/base.txt \
	--replace "boto3~=1.14.23" "boto3~=1.14" \
	--replace "docker~=4.2.0" "docker~=4.3.1" \
	--replace "python-dateutil~=2.6, <2.8.1" "python-dateutil~=2.6" \
	--replace "requests==2.23.0" "requests~=2.24" \
	--replace "serverlessrepo==0.1.9" "serverlessrepo~=0.1.9"
    '';

    doCheck = false;

    postFixup = ''
      mkdir -p $out/bin
      wrapProgram $out/bin/sam --set SAM_CLI_TELEMETRY 0
    '';

    meta = with lib; {
      homepage = "https://github.com/aws/aws-sam-cli";
      description = "CLI tool to build, test, debug, and deploy Serverless applications using AWS SAM";
      license = licenses.asl20;
      maintainers = with maintainers; [ aws ];
    };
  }
)

I'm not very good at writing nix expressions, so I'm sure it can be improved, but it worked for me:

do you mind rebasing? got some conflicts

I started a quick rebuild on my side just now but should work like the previous push

By the way, in the meantime, the version 1.13.1 has been released, do you mind if I update this pr to jump to that version, or should I open a new PR ?

Well too fast ... some dependency changed ??

By the way, in the meantime, the version 1.13.1 has been released, do you mind if I update this pr to jump to that version, or should I open a new PR ?

Yea this PR is a version bump, feel free to bump it to latest

@jonringer thx it is ready

@freezeboy please target master because for a python packages a 100 to 500 rebuilds are quick to build.

@freezeboy please target master because for a python packages a 100 to 500 rebuilds are quick to build.

oh, sorry, I fixed the current build, and that caused some conflicts

oh, sorry, I fixed the current build, and that caused some conflicts

Rebased + conflict resolved :crossed_fingers:

Rebased + conflict resolved :crossed_fingers:

@freezeboy You might want to bump it once more: https://github.com/aws/aws-sam-cli/releases/tag/v1.14.0

@freezeboy You might want to bump it once more: https://github.com/aws/aws-sam-cli/releases/tag/v1.14.0

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 104782 run on x86_64-linux 1

1 package built:

aws-sam-cli

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:
aws-sam-cli:

Please consider this feature to be alpha.
A substituteInPlace with an unmatched pattern got detected:
substituteStream(): WARNING: pattern 'serverlessrepo==0.1.9' doesn't match anything in file 'requirements/base.txt'

Please check the offending substituteInPlace for typos or changes in source.

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 104782 run on x86_64-linux 1

1 package built:

aws-sam-cli

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:
aws-sam-cli:

Please consider this feature to be alpha.
A substituteInPlace with an unmatched pattern got detected:
substituteStream(): WARNING: pattern 'serverlessrepo==0.1.9' doesn't match anything in file 'requirements/base.txt'

Please check the offending substituteInPlace for typos or changes in source.

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 104782 run on x86_64-darwin 1

1 package built:

aws-sam-cli

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:
aws-sam-cli:

Please consider this feature to be alpha.
A substituteInPlace with an unmatched pattern got detected:
substituteStream(): WARNING: pattern 'serverlessrepo==0.1.9' doesn't match anything in file 'requirements/base.txt'

Please check the offending substituteInPlace for typos or changes in source.

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 104782 run on x86_64-darwin 1

1 package built:

aws-sam-cli

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:
aws-sam-cli:

Please consider this feature to be alpha.
A substituteInPlace with an unmatched pattern got detected:
substituteStream(): WARNING: pattern 'serverlessrepo==0.1.9' doesn't match anything in file 'requirements/base.txt'

Please check the offending substituteInPlace for typos or changes in source.

@hirenashah  Ok updated ... again
Really sad this trivial change is pending since November 2020 ...

@hirenashah  Ok updated ... again
Really sad this trivial change is pending since November 2020 ...

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 104782 run on x86_64-darwin 1

1 package built:

aws-sam-cli

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:
aws-sam-cli:

Please consider this feature to be alpha.
A substituteInPlace with an unmatched pattern got detected:
substituteStream(): WARNING: pattern 'serverlessrepo==0.1.9' doesn't match anything in file 'requirements/base.txt'

Please check the offending substituteInPlace for typos or changes in source.

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 104782 run on x86_64-darwin 1

1 package built:

aws-sam-cli

The following issues got detected with the above build packages.
Please fix at least the ones listed with your changed packages:
aws-sam-cli:

Please consider this feature to be alpha.
A substituteInPlace with an unmatched pattern got detected:
substituteStream(): WARNING: pattern 'serverlessrepo==0.1.9' doesn't match anything in file 'requirements/base.txt'

Please check the offending substituteInPlace for typos or changes in source.

If the stale substituteInPlace is removed this can be merged. The version bump could also have been a new PR.

If the stale substituteInPlace is removed this can be merged. The version bump could also have been a new PR.

So the remaining task is simply to delete this one line?
      --replace "serverlessrepo==0.1.9" "serverlessrepo~=0.1.9" \

So the remaining task is simply to delete this one line?
      --replace "serverlessrepo==0.1.9" "serverlessrepo~=0.1.9" \

I think so.

Rebased, dangling substition removed, built locally, and force pushed


init with Header method not found in Fremework. When i integrated using podfile

Hi, I integrated the EventSource pod using

pod 'EventSource'

But i did not find init with header method
public init(url: String, headers: [String : String] = [:]) {} in the framework. But i could see that method in sample app which you provided. Currently using EventSource (1.0.4).  Am i using correct version ? where else going wrong?

Version 3.0 is correctly working with CocoaPods. Tested it and seems to be fine.
As @vpdn mentions import IKEventSource


Macedonian translations.

Hello there!
Added macedonian translations to help out with #28
Happy hacktoberfest! Thanks for opting in your project!
Cheers!

Hello @krisfremen. Thanks for your PR. Happy hacktoberfest!


unable to install in windows7

I try to install "Atom" by installer, AtomSetup.exe.
However, I can not install and it pop up that error message, "Unable to wright to C:\users\name\appdata\local\squirreltemp - IT policies may be restricting access to this folder"
and do not emit error log-text.
I never have installed atom in my computer, and I prepare the /squirreltemp folder before execute "AtomSetup.exe", and emitting the message, "Failed to extract installer".  and do not emit log as with above.

I never have installed atom in my computer, and I prepare the /squirreltemp folder before execute "AtomSetup.exe", and emitting the message, "Failed to extract installer".

You do not need to "prepare" any temp folders. There seems to be a permissions issue, so maybe double-check that there is no problem accessing the path described by the error under your user account?

@batjko
Thank you for replying :)
So, I try also execute .exe file as Administrator role, but I can not.
Just maybe, there are another way to remove access restriction... I do not know...

Ok, running as Administrator should also not be necessary, as most people install it fine under their normal accounts.
But firewall or proxy settings could be an issue. Any chance you are behind one of those?

@batjko
I try to install canceling the firewall one time, So I think that there are the problems of setting proxy.
Are there pre-setting of proxy to install?

I can solve this problem myself just now.
I can install the process that I move AtomSetup.exe file into "c:/users//appdata/local/squirreltemp/" and execute this.
If there is no "squirreltemp", you make the name's directory.
Thanks @batjko and so on : )

Hm, alright. Glad you got it to work then! :+1:

If anyone else has this issue as well (I have Windows 8, 64 bit, tried cc cleaner, deactivating the firewall, the workaround above) - for me nothing seemed to work either, so I simply downloaded the
atom-windows.zip
from here
https://github.com/atom/atom/releases/tag/v1.12.3
And voilà, everything worked quickly and perfecto.


Set up an instance of InvenioRDM

Is your feature request related to a problem? Please describe.
This builds on

#10
#11
#14

Describe the solution you'd like
Install an instance of InvenioRDM, as per the docs

We got a first test instance up and running yesterday. Documentation to follow.

Christian from IGB IT has set up a virtual machine for our testing - BUT, due to security/policy issues, it is only access from IGB owned and maintained devices, making it untenable for our use.
Inquiring if there are any alternatives that the IGB can provide.

As an alternative, we are exploring

#46
#47


Multiple Windows (SwapChain) sample?

Would be possible to add multiple swap chain example ( for desktop ) platforms?
Thank you

Nothing planned. But having multiple windows with multiple swap chains is pretty straightforward. Just create a surface for each window (passing e.g. the HWND and HINSTANCE on Windows) and use that for the swap chains.

So the confusing part is that it seems that RenderPasses and therefore GraphicsPipelines are dependent on the Surface's format. So do you create these objects per window (super annoying for sharing materials) or do you hope the render passes are going to be compatible (meaning the surface format is always the same) and create a 'dummy' window+surface during initialization and use it's format?
Without doing this, the physical device selection can't verify with vkGetPhysicalDeviceSurfaceCapabilitiesKHR that the surface will be compatible. Then for each real window, you would need to create a surface for it and verify that its format/caps matched. I would think that they would normally be the same as the initial dummy window.

@SaschaWillems @Ziflin Curious if you have any after-the-fact comment/suggestion on the problem you @Ziflin described? I'm also trying to implement multiple viewport and wondering what assumption I can make about matching surface format.

@ocornut I never found a great example, but I just ended up going with the same (annoying) setup as I mentioned and during initialization I create a temporary window and create a surface from that that I keep around. Then during 'actual' window creation, I create a new surface for that window and verify that it has a surface format (GetPhysicalDeviceSurfaceFormatsKhr) that has a matching format and colorspace as the initialization surface.
I'm not sure why this isn't addressed better somewhere...

On a related but slightly different situation, do you have an example for driving one surface over multiple devices with monitors on each? I have been looking but seem to have missed the ability to tell if the a surface is completely not on one of the devices, so can save not rendering to it.
Even just a hint to the correct API struct or func would be greatly appreciated.
Thanks.

@ocornut and @Ziflin curious if any of you ever found a better way to go about this than creating a dummy window?


fix sauce flakiness

This seems to fix things. I think the browserDisconnectTolerance : 2 portion was what fixed things the most, as legacy Edge seems to now consistently have 2 disconnects before getting through all the tests.

Nice, good work @margaree!


FFT now linked to filtered EEG data

FFT now happens in dataProcessing.process(), and now it only calculates filtered data instead of raw data.
As a result dataProcessing.process() doesn't take in fftBuff as one of the argument, while dataProcessing_User.process() remains the same (still has reference to fftData).
As a result the function initializeFFTObjects() is no longer in need and was removed.

This version works, though now dataprocessing.process() don't take fftBuff but dataProcessing_User.process() still takes fftBuff as one of the argument, and this asymmetricity could cause some confusion. And anyway none of the arrays passed by function are protected.
If there is an array float[] samplearray composed of all 0 values, and a function void samplefunction( float[] anotherarray) { anotherarray[0] = 1; }. If you call samplefunction(samplearray), samplearray can still be modified.
So we may plan to remove some of these array passing feature of the functions to simplify the look.

ready to go


add descrption to landing page when there is no images

Description
This commit adds description and link to documentation to the landing page when there are no images
Fixes related to issue: https://issues.redhat.com/browse/THEEDGE-3446
before the changes:

after the changes:

Type of change
What is it?

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

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] 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
[x] I run npm run lint:js:fix to check that my code is properly formatted

Codecov Report
Patch coverage: 50.00% and no project coverage change.

Comparison is base (c230771) 27.74% compared to head (b8ea93a) 27.74%.

:exclamation: Current head b8ea93a differs from pull request most recent head f6caa63. Consider uploading reports for the commit f6caa63 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #701   +/-   ##
=======================================
  Coverage   27.74%   27.74%
=======================================
  Files         130      130
  Lines        3302     3302
  Branches     1145     1145
=======================================
  Hits          916      916
  Misses       2152     2152
  Partials      234      234

Impacted Files
Coverage Δ

src/Routes/ImageManager/ImageSetsTable.js
40.74% <ø> (ø)

src/components/Empty.js
92.30% <50.00%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Issue with jaxlib feedstock wrt nvcc dependency. ( observed while building using build feedstock cmd ) - ppc

`conda_build.exceptions.DependencyNeedsBuildingError: Unsatisfiable dependencies for platform linux-ppc64le: {'nvcc_linux-ppc64le=12.2'}
[OPEN-CE-ERROR]-11 Unable to build recipe: jaxlib
Unsatisfiable dependencies for platform linux-ppc64le: {'nvcc_linux-ppc64le=12.2'}
ERROR:OPEN-CE:[OPEN-CE-ERROR]-11 Unable to build recipe: jaxlib
Unsatisfiable dependencies for platform linux-ppc64le: {'nvcc_linux-ppc64le=12.2'}
ERROR OPEN-CE:<module>(139): [OPEN-CE-ERROR]-11 Unable to build recipe: jaxlib
Unsatisfiable dependencies for platform linux-ppc64le: {'nvcc_linux-ppc64le=12.2'}`

these are related to 1.11.2


Support AWS.SharedIniFileCredentials()

Add support for SharedIniFileCredentials

sorry...I mistakenly forked your repo instead of ingenieux/aws-sdk-typescript


"Fixed/Freely Moving Spiking Frequency Correlation" function freezes

This happens when toggling between "Free Experiments" drop down menu.
Example .mcomp file = CA326_C_day3-CA407_1_day2

This function also freezes when just running it. The whole gui freezes

Both of these issues have been resolved and updated on Subiculum. Note that you may need to recreate the .mcomp files as older files may cause errors (Note also that I have recreated "CA326_C_dya3-CA407_1_day2.mcomp" and is the file I have been using to test the Spiking Frequency Correlation functions).


Fix basics for a first release

Before I can release my first version (0.1 probably), I have to think of the following subjects.
License
MIT license is fine.
Release strategy
To keep commits clean of versioning stuff, add some gradle parameter so you can publish with a command like gradle publish -Pversion=0.1.
Uploading to Maven Central
I have no clue how this works, so I have to figure this out.

Release 0.1 has been deployed! I consider this issue closed.
https://search.maven.org/artifact/io.github.ricoapon/readable-regex

Release 0.1 has been deployed! I consider this issue closed.
https://search.maven.org/artifact/io.github.ricoapon/readable-regex


obs websocket v5.0.2

Noticed they have a tag for it, but no release just yet. Gonna keep it open for now

I guess the v5.0.2 tag never got an official release. I see a tag for v5.1.0 already.


Frameworks adaptations

Update documentation with implementations for a plugin in popular frameworks:

VueJs (maybe Nuxt)
React (maybe Gatsby, Next)
Angular

I agree. Trying to use this in next.js and Im getting some rendering issues. Last frame is still visible

@Vaqxin Can you share the or part of the code? Try setting height and width of the container..

@Vaqxin Had the same issue, created a pull request with fix for that here

@MateuszJurus 👍

I second this suggestion - I'd like to use this in a React project but currently not having much luck implementing it myself. A clear copy-pasteable React example would be perfect.


As a user of the bbl-up task I would like to provide GCP credentials as a task param instead of as a path to a file

If the task only accepts a file, that leads me to check it into GitHub or put it in an S3 bucket. I would prefer to provide the credentials in the pipeline directly (like the AWS credentials) so I can store them in a more secure way with my other pipeline secrets.

Hey @mmb. This would actually require a change to bbl -- it currently expects that your credentials are stored in a file. @evanfarrar, do you have any thoughts on this? Would it make sense for bbl to allow a string input instead of a file input for GCP credentials?

Could the task write the credentials to a file before passing it to bbl?
Our workaround for this is to have a Concourse task that writes a param to a file.

We had discussed this awkwardness on the Infrastructure team when we recently started using the cf-deployment-concourse tasks ourselves. We will change the flag to take the contents of the credential file (while preserving file path for backwards compatibility).

Tracking this in
https://www.pivotaltracker.com/story/show/142097551

Hey @mmb. Since we've upgrade to bbl 3.0.4, this should probably work. Want to give it a try and report back?

This works now. Thanks @dsabeti and @evanfarrar.


golang: include go.env in GOROOT

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[ ] Ready to merge

Summary

What does the PR accomplish, why was it needed?
Include go.env in GOROOT which is now the default value from where GOPROXY value is read
Cherry-Pick of: #8004
Change Log

Include go.env in GOROOT

Does this affect the toolchain?

NO
Associated issues

https://github.com/golang/go/issues/61928

Links to CVEs

NA

Test Methodology

Pipeline build id: PR-8021

/cc @dagood

@mfrw Can this fix be cherry-picked to 2.0? I think we have the same issue there.


[pubsub]: Node ID private key as parameter.

Motivation
According to https://github.com/airalab/robonomics/issues/46 is better to dedicate node identity and store it into a file for long term usage.
Steps

[ ] Add into identity module function to save/load peer private key from file.
[ ] Move peer identity into Gossipsub::new() function parameter.

Is it still relevant? @akru

@akru I found this task in the project dedicated to Sensors Map. Is it still active task, should I keep it alive in the project task board ?


Specify the path to of data and log.

Description
TBD
Steps to Reproduce
Omit
Versions
develop
Additional Information
----------------Chinese-------------
可指定 log 和 data 文件夹的路径

#221

Has  someone work on this issue?

Has someone work on this issue?

If you have more time, can you help with this task https://github.com/cryptape/cita-common/issues/177.

Has someone work on this issue?

I will.

Has someone work on this issue?

If you have more time, can you help with this task cryptape/cita-common#177.

This's also me.

Later.
new solution, check #283


Make ObjectStore implement IObjectStore

see Issue on codeplex nr Id #7286
https://sharpsnmplib.codeplex.com/workitem/7286
Make ObjectStore inherit from an Interface: IObjectStore, in order to allow customization of the ObjectStore:
https://sharpsnmplib.codeplex.com/SourceControl/latest#SharpSnmpLib/Pipeline/ObjectStore.cs
This is necessary for applications which do not necessarly know all OID's managed by the SNMP Server. The Current Implementation requires knowledge of all OID's on startup/before requesting the Object.
public interface IObjectStore{
public ScalarObject GetObject(ObjectIdentifier id);
public ScalarObject GetNextObject(ObjectIdentifier id);
public void Add(ISnmpObject newObject);
}

Fixed in #14.


Strict safety improvements toolchain workaround

This is https://github.com/swiftlang/swift/pull/78332, but with https://github.com/swiftlang/swift/pull/78327 temporarily reverted because it looks like it caused this build failure:
/Users/ec2-user/jenkins/workspace/swift-PR-toolchain-macos/branch-main/buildbot_osx/swift-macosx-x86_64/lib/swift/xros/Swift.swiftmodule/arm64-apple-xros.private.swiftinterface:2371:2: error: '@backDeployed' requires that global function '_diagnoseUnavailableCodeReached()' have a body
 2369 | @usableFromInline
 2370 | @inline(never) internal func _diagnoseUnexpectedEnumCase<SwitchedValue>(type: SwitchedValue.Type) -> Swift.Never
 2371 | @backDeployed(before: macOS 14.0, iOS 17.0, watchOS 10.0, tvOS 17.0)
      |  `- error: '@backDeployed' requires that global function '_diagnoseUnavailableCodeReached()' have a body
 2372 | @usableFromInline
 2373 | @inline(never) @_semantics("unavailable_code_reached") internal func _diagnoseUnavailableCodeReached() -> Swift.Never

@swift-ci please build toolchain macOS


Bugfix Makefile: target "test" contains spaces and not tabs

I add a .editorconfig to avoid it ;)

Without being an expert in .editorconfig :+1:


Handle file uri in CommentAuthorInformation.iconPath (fix #174690)

This PR fixes #174690, handling the case where the CommentAuthorInformation.iconPath uri uses the file scheme (for example, to specify an avatar that is bundled with the extension).

Modified comment-sample at https://github.com/gjsjohnmurray/vscode-extension-samples/tree/show-iconpath uses GitHub (https) avatar for first comment, then embedded image for second.
For the embedded icon it uses file:// uri unless extension.extensionKind is Workspace, in which case it sets scheme to vscode-remote and authority to vscode.env.remoteName. See https://github.com/gjsjohnmurray/vscode-extension-samples/blob/c9ec78c3bcc67d52cd493ad4e0514aa459fdfd8f/comment-sample/src/extension.ts#L26-L31

For the embedded icon it uses file:// uri unless extension.extensionKind is Workspace, in which case it sets scheme to vscode-remote and authority to vscode.env.remoteName. See https://github.com/gjsjohnmurray/vscode-extension-samples/blob/c9ec78c3bcc67d52cd493ad4e0514aa459fdfd8f/comment-sample/src/extension.ts#L26-L31

@alexr00 ideally the extension wouldn't have to do this itself, but I haven't found a way of getting it done automatically.

ideally the extension wouldn't have to do this itself, but I haven't found a way of getting it done automatically.

Just pushed a change that does this.

@gjsjohnmurray thanks for the PR! There's some logic somewhere that will automatically transform the URI if we send it from the extension host to the renderer as a URIComponents. The problem here is that the URI is being toStringed when it gets converted to a data transfer object 🙈.
The best fix would be to make it a URIComponents so that it get's automatically transformed. If you'd like to make a PR with this change then please do! Otherwise, I'll fix it myself in the next couple weeks.


[VS2013/2015] Named class expressions are not formatted correctly

Class expression below does not have correct shape after formatting
let z = class           B                {}

looks fixed on latest.


Broken syntax highlighting

Initial checklist

[X] I read the support docs
[X] I read the contributing guide
[X] I agree to follow the code of conduct
[X] I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions
MDX v1.8.9
Link to runnable example
No response
Steps to reproduce
Open VSCode (v1.92.0), with MDX extension (v1.8.9), and the syntax highlighting on MDX files is broken.
This was working yesterday and appears to have suddenly become broken when I updated VSCode to the latest version.
Syntax highlighting works fine up until the closing 3 dashes --- at the end of the frontmatter, and from then on out it's broken:

Note how the top --- is correctly orange, but the bottom --- is not.
All text after this appears red when it was previously white:

I have done the typical extension uninstall/reinstall, also restarted my machine and VSCode since encountering this issue, so it's not that.
Expected behavior
The syntax highlighting works.
Actual behavior
The syntax highlighting doesn't work.
Runtime
Node v20
Package manager
npm v10
OS
Windows
Build and bundle tools
Other (please specify in steps to reproduce)

Duplicate of https://github.com/wooorm/markdown-tm-language/issues/10

https://github.com/wooorm/markdown-tm-language/issues/10#issuecomment-2265019049 solved this issue for me.


Design FileStore interface

This is now done - though I suspect we'll refine it. I'm closing for now.


Length of the table key name must not exceed 28 characters. Longer key names are prone to cause SQL errors. This warning will become an error in a future release.

Hi,
I have an extension with this warning, hen I upload the PTE Extension on the Business Central on the cloud (Sandbox).
This key have the ObsoleteState = Removed, but the extension management show already this warning.
Will I have some problem in future ?
Version: IT Business Central 15.2 (Platform 15.0.39461.40328 + Application 15.2.39060.0)
Thank you,
Roberto.

Hi! You might have problems if your users use a very long company name.
You are getting this warning because keys are still created although they are marked as ObsoleteState = Removed. We have it on our backlog to allow removing obsolete schema elements completely, but I cannot provide an ETA at this point in time.

I am closing this issue because it appears that it has been resolved. Please open a new issue if you believe this has not been resolved and reference the current issue.


Test failed on Mac(M1)

Description
go test failed.
Steps to reproduce the issue:

git pull
go test

Describe the results you received:
--- FAIL: TestCalcCellValue (6.90s)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "799.501207124235"
        	            	actual  : "799.5012071242348"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-799.501207124235
        	            	+799.5012071242348
        	Test:       	TestCalcCellValue
        	Messages:   	=BESSELK(0.05,2)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "0.0080412665831637"
        	            	actual  : "0.00804126658316381"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.0080412665831637
        	            	+0.00804126658316381
        	Test:       	TestCalcCellValue
        	Messages:   	=RATE(48,-200,8000,3,1,0.5)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "1.32646097270444"
        	            	actual  : "1.32646097270443"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-1.32646097270444
        	            	+1.32646097270443
        	Test:       	TestCalcCellValue
        	Messages:   	=F.INV.RT(0.1,79,86)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "0.49833703055518686-0.5910838417210451i"
        	            	actual  : "0.4983370305551868-0.591083841721045i"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.49833703055518686-0.5910838417210451i
        	            	+0.4983370305551868-0.591083841721045i
        	Test:       	TestCalcCellValue
        	Messages:   	=IMSEC(COMPLEX(1,-1))
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "0.49833703055518686+0.5910838417210451i"
        	            	actual  : "0.4983370305551868+0.591083841721045i"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.49833703055518686+0.5910838417210451i
        	            	+0.4983370305551868+0.591083841721045i
        	Test:       	TestCalcCellValue
        	Messages:   	=IMSECH(COMPLEX(1,-1))
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "-0.029999999999999985-0.039999999999999994i"
        	            	actual  : "-0.02999999999999998-0.039999999999999994i"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	--0.029999999999999985-0.039999999999999994i
        	            	+-0.02999999999999998-0.039999999999999994i
        	Test:       	TestCalcCellValue
        	Messages:   	=IMPOWER("2+4i",-2)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "0.0137197479028414"
        	            	actual  : "0.0137197479028436"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.0137197479028414
        	            	+0.0137197479028436
        	Test:       	TestCalcCellValue
        	Messages:   	=CONFIDENCE.NORM(0.05,0.07,100)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "0.6875"
        	            	actual  : "0.687500000000001"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.6875
        	            	+0.687500000000001
        	Test:       	TestCalcCellValue
        	Messages:   	=AMORLINC(150,"01/01/2015","09/30/2015",20,6,15%,4)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "0.0061834131621292"
        	            	actual  : "0.00618341316212921"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.0061834131621292
        	            	+0.00618341316212921
        	Test:       	TestCalcCellValue
        	Messages:   	=RATE(60,-1000,50000)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "0"
        	            	actual  : "5.55111512312578E-17"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0
        	            	+5.55111512312578E-17
        	Test:       	TestCalcCellValue
        	Messages:   	=PERCENTILE.EXC(A1:A4,0.2)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "2.4289904975637864+0.5489546632866347i"
        	            	actual  : "2.428990497563786+0.5489546632866347i"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-2.4289904975637864+0.5489546632866347i
        	            	+2.428990497563786+0.5489546632866347i
        	Test:       	TestCalcCellValue
        	Messages:   	=IMLOG2("5+2i")
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "0.0137197479028414"
        	            	actual  : "0.0137197479028436"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.0137197479028414
        	            	+0.0137197479028436
        	Test:       	TestCalcCellValue
        	Messages:   	=CONFIDENCE(0.05,0.07,100)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "0.0419422478838651"
        	            	actual  : "0.0419422478838649"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.0419422478838651
        	            	+0.0419422478838649
        	Test:       	TestCalcCellValue
        	Messages:   	=YIELDMAT("01/01/2017","06/30/2018","06/01/2014",5.5%,101,0)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "-12.789855163794034"
        	            	actual  : "-12.789855163794032"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	--12.789855163794034
        	            	+-12.789855163794032
        	Test:       	TestCalcCellValue
        	Messages:   	=BESSELY(0.05,1)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "0.0976269355643988"
        	            	actual  : "0.0976269355643989"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.0976269355643988
        	            	+0.0976269355643989
        	Test:       	TestCalcCellValue
        	Messages:   	=YIELD("01/01/2010","06/30/2015",10%,101,100,4,4)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "0.0419422478838651"
        	            	actual  : "0.0419422478838649"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.0419422478838651
        	            	+0.0419422478838649
        	Test:       	TestCalcCellValue
        	Messages:   	=YIELDMAT("01/01/2017","06/30/2018","06/01/2014",5.5%,101)
    calc_test.go:1740:
        	Error Trace:	calc_test.go:1740
        	Error:      	Not equal:
        	            	expected: "1.32646097270444"
        	            	actual  : "1.32646097270443"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-1.32646097270444
        	            	+1.32646097270443
        	Test:       	TestCalcCellValue
        	Messages:   	=FINV(0.1,79,86)
--- FAIL: TestCalcXIRR (0.00s)
    calc_test.go:4088:
        	Error Trace:	calc_test.go:4088
        	Error:      	Not equal:
        	            	expected: "0.09443907444452"
        	            	actual  : "0.0944390744445201"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.09443907444452
        	            	+0.0944390744445201
        	Test:       	TestCalcXIRR
        	Messages:   	=XIRR(A1:A6,B1:B6)
    calc_test.go:4088:
        	Error Trace:	calc_test.go:4088
        	Error:      	Not equal:
        	            	expected: "0.0944390744445201"
        	            	actual  : "0.0944390744445199"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1 +1 @@
        	            	-0.0944390744445201
        	            	+0.0944390744445199
        	Test:       	TestCalcXIRR
        	Messages:   	=XIRR(A1:A6,B1:B6,0.1)
2022/03/15 00:59:41 xml decode error: XML syntax error on line 1: invalid UTF-8
2022/03/15 00:59:41 xml decode error: XML syntax error on line 1: invalid UTF-8
2022/03/15 00:59:41 xml decode error: XML syntax error on line 1: invalid UTF-8
2022/03/15 00:59:42 xml decode error: XML syntax error on line 1: invalid UTF-8
2022/03/15 00:59:42 xml decode error: XML syntax error on line 1: invalid UTF-8
2022/03/15 00:59:42 xml decode error: XML syntax error on line 1: invalid UTF-8
2022/03/15 00:59:42 xml decode error: XML syntax error on line 1: invalid UTF-8
2022/03/15 00:59:43 xml decode error: XML syntax error on line 1: invalid UTF-8
2022/03/15 00:59:51 xml decode error: XML syntax error on line 1: invalid UTF-8
2022/03/15 00:59:51 xml decoder error: XML syntax error on line 1: invalid UTF-8
FAIL
exit status 1
FAIL	github.com/xuri/excelize/v2	17.246s

Output of go version:
go version go1.17.8 darwin/arm64

Excelize version or commit ID:
4220bf4

Environment details (OS, Microsoft Excel™ version, physical, etc.):
macOS 12.2.1 (M1)

Thanks for your issue. I have fixed this issue. Please try upgrade to the master branch code.


Add Ecoute

By submitting this pull request, I promise I have read the contribution guidelines twice and made sure my submission follows it.
⬆⬆⬆⬆⬆⬆⬆⬆⬆⬆

Where is it hosted?

How is it a browser extension?

Where do you think it would be more appropriate?


When are inclineCompletions shown?

I see from the interface comments that inlineCompletions are requested whenever the users stops typing.  The question I have is how does the editor determine this?  Is there an existing setting that controls the quiescence period before the editor decides the user has stopped?  Is it possible to increase this or should I just wait in the handler?
@hediet

Thank you.  Reading through your PR and #140557 there is a reference to some documentation of the delay service.  Could you share a pointer?

I see from the code that the bounds are set to 50ms and 200ms.  How were these numbers chosen and what was the value before the adaptive debounce service was available?

Before it was always just 50ms

I've opened an issue to tune these parameters with ExP #151447.  Please review.

Let's discuss this in #151447.


Slow internal name resolution

Rancher Version: v0.63.1
Docker Version: 1.10.3, build 20f81dd
OS: Debian GNU/Linux 8 (jessie)
Steps to Reproduce: resolve an internal name
Results: slow internal name resolution
Expected: fast internal name resolution
From inside one of the containers:
/usr/src/app # cat /etc/resolv.conf
search tv2-jukebox.rancher.internal asset.tv2-jukebox.rancher.internal rancher.internal
nameserver <IP_ADDRESS>

/usr/src/app # time wget -O - http://db:5984
Connecting to db:5984 (<IP_ADDRESS>:5984)
{"couchdb":"Welcome","uuid":"bb8fb832bdebabe9925fbcf6b9dba5a8","version":"1.6.1","vendor":{"version":"1.6.1","name":"The Apache Software Foundation"}}
-                    100% ...
real    0m 5.00s
...

/usr/src/app # time wget -O - http://<IP_ADDRESS>:5984
Connecting to <IP_ADDRESS>:5984 (<IP_ADDRESS>:5984)
{"couchdb":"Welcome","uuid":"bb8fb832bdebabe9925fbcf6b9dba5a8","version":"1.6.1","vendor":{"version":"1.6.1","name":"The Apache Software Foundation"}}
-                    100%  ...
real    0m 0.00s
...

External domains resolves just fine and local ping times are low, any steps that can be taken to further debug this?
Thanks.

@retardtank Can you try v1.0.0-rc6, there's a bunch of changes made since 0.63 for DNS performance.

@vincent99: Same problem...

Unfortunately the problem still persists with v1.0.0-rc6. Copied the db from the old rancher server, wiped all containers and rancher images. Then started v1.0.0-rc6 with the db directory bind mounted...

I experience the same problem with an Alpine Linux image (which is the new default base image of Docker). The name resolution seems to get an timeout for the pure hostname after 5 seconds, causing it to try hostname.stack.rancher.internal which succeeds.
Ubuntu on the other side (14.04 and 15.10) works just fine.

@HardcorEViruS Yes. That became our solution too, but just adding the stack was enough (db -> db.jukebox). Though it has worked fine before using Alpine images as well, I guess it's circumstantial to the network environment. This particular setup is on a closed network (behind a corporate proxy) which we don't have much control of, and exactly the same setup has no issues on aws, etc...

@retardtank I tested it in the same stack at the same time with an Alpine and the two Ubuntu images and the Alpine one had the delay while the Ubuntu ones didn't. Unfortunately in our case it is not a solution to append the stack as this would

This is likely caused by the way the musl-libc (which Alpine uses) resolver works, combined with (I guess) how the DNS servers on the network which this setup is on is configured. I kind of knew of the musl-libc resolver, but initially missed to take that into account for this case. Workaround is to not use local names for queries or images based on systems that uses musl-libc (Alpine! :D)...
Thanks.

This is a bug in rancher-dns. Specifically, it returns ServFail rather than NxDomain when the requested name does not exist. ServFail is not an answer as to whether the name exists or not, just an indication that something went wrong on the nameserver attempting to resolve it, so musl continues to retry until it times out. The offending code is at:
https://github.com/rancher/rancher-dns/blob/master/main.go#L406
See also the definition of dns.HandleFailed:
https://github.com/miekg/dns/blob/4744e915eb51a9defb5fb13c24ce2c8408d2fd98/server.go#L90


Animated Follow Button Component with Multiple Animation Options

Description
I am proposing the creation of a new AnimatedFollowButton component that features various animation types, including up-to-down down-to-up left-to-right right-to-left zoom-in and zoom-out. This component allows for customizable text and styling options while ensuring a smooth user experience with the framer-motion library. The implementation enhances flexibility and aesthetic appeal in UI interactions.
Component Props:

initialText: (React.ReactElement | string) - The text or element displayed when the button is in its initial state.
changeText: (React.ReactElement | string) - The text or element displayed when the button is clicked.
className: (string, optional) - A custom CSS class for styling the button.
changeTextClassName: (string, optional) - An additional custom CSS class specifically for the changeText element.
animationType: ("up-to-down" | "down-to-up" | "left-to-right" | "right-to-left" | "zoom-in" | "zoom-out", optional) - A prop to define the type of animation applied when changing states. Defaults to "up-to-down".

This component can significantly enhance user interactions and improve the overall user experience in applications where button feedback is crucial.
Animation Preview

Screenshot/Video:

Please assign this to me @hari

@hari I have already made a PR (#304) can you please review it


Where is the UiSystemDemo.cpp file?

In guitar_pedal_ui.cpp it is written:
// These will be called from the UI system. @see InitUi() in UiSystemDemo.cpp
void FlushCanvas(const UiCanvasDescriptor& canvasDescriptor)
{
    ...
}

I can't seem to find the file in the repo.

Sorry, that's a stray comment from where I copied that function from out of the Electrosmith Lib Daisy Examples.     There is an InitUI() function in guitar_pedal_ui.cpp that does the same init.  You can see it here:


Docs: Update docs homepage with improved links and CTAs

Description
Docs home page was built as a very quick first iteration, and with current traffic, feel like we could provide better information and more useful resources to the users visiting the site. This is our PH heatmap for the past 7 days:

Proposal:

Remove the three tiles and replace them with "Recommended Reading" & move "Diverse Widget Collection" to be a third pill CTA
Add CTAs for FlowFuse below this to help people get started with a NR Instance quickly.

Epic/Story
No response
Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate

@joepavitt There's two links to GH now, in the middle and top nav bar. Seeing how little contributions we get I'd remove the button in the middle.
The more colorful display of recommended reading I think is a good iteration. I'd like to get one of those 3 when there's an e-book to download. But that's a nth iteration thing.

@joepavitt Wouldn't it be nice to show the string to search for in Node-REDs manage pallette on the landing page? That's the one thing you'd like to know as Node-RED dev?

There's two links to GH now, in the middle and top nav bar. Seeing how little contributions we get I'd remove the button in the middle.

There always has been, but I'm glad you've said that as I wanted to do the same. I shall remove it.

Wouldn't it be nice to show the string to search for in Node-REDs manage pallette on the landing page? That's the one thing you'd like to know as Node-RED dev?

I'll see what I can do


Reenable some raw buffer tests in release build.

These subtests were actually meant to test the raw buffer
type itself, not its slice type. So adding an init(rebasing:)
does what we want.
Now that the Collection tests are wired up, these test cases will be run on the
slice type automatically. No need to do it here.

@swift-ci test OS X.

@swift-ci smoke test linux.


Dev:lite - div.ws-preview-html should wrap examples. Make "workspace" dir the docroot?

To match the existing workspace markup and for our example styles to work correctly, we need
 to wrap the example code.
https://github.com/patternfly/patternfly-next/blob/master/build/gulp/codeTransformer.js#L10
could be something like:

${toWrap}

You can verify this fixes this big space between the dropdown kebab icon and the menu on the dropdown component's examples (it's the 5th example).

Also is there any value in using this workspace to navigate anything outside of the "workspace" dir at http://localhost:3000/workspace? Assuming not, can that dir just be the document root for this server so that / shows you components, layouts, demos, and utilities?
cc @mattnolting @christiemolloy

The workspace has to load files from /dist and /assets, so that's why we can't just serve the /workspace directory.
As for the ws-preview-html, you found the right place to add it at https://github.com/patternfly/patternfly-next/blob/master/build/gulp/codeTransformer.js#L10!

:tada: This issue has been resolved in version 2.57.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update doc link

What problem does this PR solve?
Update the link to the [Develop a New Chaos] doc
What is changed and how does it work?
Check List
Tests

Unit test
E2E test
Manual test (add detailed scripts or steps below)
No code

Code changes

Has Go code change
Has CI related scripts change
Has Terraform scripts change

Side effects

Breaking backward compatibility

Related changes

Need to update the documentation

Does this PR introduce a user-facing change?:

NONE

Codecov Report

Merging #235 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #235   +/-   ##
=======================================
  Coverage   43.64%   43.64%
=======================================
  Files          18       18
  Lines         685      685
=======================================
  Hits          299      299
  Misses        353      353
  Partials       33       33

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 ec53426...b54b03b. Read the comment docs.


Disable SSL verification using PKCS#12-formatted certificates

Kitura-NIO doesn't support pfx certificates
Issue : IBM-Swift/Kitura-NIO#14
Should enable this once the issue is addressed.
Checklist:

[x] If applicable, I have updated the documentation accordingly.
[x] If applicable, I have added tests to cover my changes.

Closing as this is stale and has conflicts. @nethraravindran reopen whenever you are ready!


[Question] Lightning Deprecation Warning

:question: Question

I am getting this error log during a docker image execution "/venv/lib/python3.8/site-packages/pytorch_lightning/core/memory.py:16: LightningDeprecationWarning: pytorch_lightning.core.memory.get_memory_profile and pytorch_lightning.core.memory.get_gpu_memory_map have been moved to pytorch_lightning.utilities.memory since v1.5 and will be removed in v1.7. rank_zero_deprecation( " and one of the solutions suggested is to use the functions of "warnings" python module but "pip install warnings" was not successful. Can any one please tell how to get rid of this "lightning depracation" warning

Dear @DSRajesh ,
I lowered the version of nevergrad which lead to an pip error due to incompatible numpy versions. This should be unrelated to that. Since the error mentions lightning v1.5 und nndet is limited to pytorch_lightning>=1.3.1,<=1.4.2 I think you probably have the wrong version installed. (I was not able to reproduce your error with described build in the readme).
So resolve this, I need more info on your env such as the pytorch and pytorch-lightning version.
Best,
Michael

The Dataset only trains for 59 Epochs and I get this error
Epoch 59: 100%|████████████████████████████████████████████| 2600/2600 [28:24<00:00,  1.53it/s, loss=-0.938, v_num=4e06]                                                                                /opt/conda/lib/python3.8/site-packages/pytorch_lightning/trainer/deprecated_api.py:32: LightningDeprecationWarning: Trainer.train_loop has been renamed to Trainer.fit_loop and will be removed in v1.6.
rank_zero_deprecation(
This is the result of nndet_env

everything else was installed based on the requirements.txt

Dear  @mibaumgartner
Here are the details of our run
RUN pip install torch==1.12.0.dev20220213+cu113 -f https://download.pytorch.org/whl/nightly/cu113/torch_nightly.html
RUN pip install torchvision==0.13.0.dev20220213+cu113 -f https://download.pytorch.org/whl/nightly/cu113/torch_nightly.html
RUN pip install torchmetrics==0.7.0 pytorch-lightning==1.5.9
Also we had used the module for nodule prediction.
Thanks
Rajesh

Dear @DSRajesh ,
I'm a bit surprised that pip did not complain about the versions since nnDetection is limited to pytorch_lightning>=1.3.1,<=1.4.2 (I did not test nndet with pt 1.12 dev so I can not comment on problems which may arise due to that version). You may want to consider to downgrade the lightning version. If it only remains a warning it might be fine for now though.


Design integration of Trust Stores and Notation Config

The notation client currently supports notation cert add and has a config spec
As we add Trust Stores and policy support, we'll need a design for how these interact.

@SteveLasker , @dtzar  - This issue should be in Notation, not in notary project, and I believe we have multiple open issues there to track the UX for configuration of trust store and trust policy.  I propose we close this here.
In summary

The trust store as specified and implemented today with directory structure, does not need configuration for adding/removing certificates for RC-1.
For signature verification, all the configuration goes inside the Trust policy that refers to trust store
For signing, configuration has to be done, and lets track it as part of the open issues in Notation repo.

I think what @SteveLasker is getting at is the design spec on how notation cert add interacts with the config / trust stores / policies.  I don't see any relevant item to track this specifically.  Agree though it should be an item in notation, not in notaryproject.

@dtzar  - I was thinking we can use one of the "user story" items you recently created or this one https://github.com/notaryproject/notation/issues/225.
We can talk more tomorrow with some live color commentary from implementers, but my understanding is that for RC-1 we do not need any CLI commands for Trust store or Trust policy

I don't think it needs to be present for RC-1 as long as the usability is reasonable.
I just don't think we should close this item out yet as I don't see it as a duplicate of another item per-se.

The command of notation cert add is now defined here https://github.com/notaryproject/notation/blob/main/specs/commandline/certificate.md, which is using CLI to manage the trust store.

As discussed in the community meeting on Nov 4, 2024, this issue can be closed as notation cert command supports CRUD on trust store and also notation policy command to manage trust policies in Notation configuration.


feat: allow to pass text features

closes #89
This PR aims to allow users to pass text features to the .text() functions this library uses to render texts
As described in the attached issue, is to apply rtl texts

I wondered wether should the options should include rtl: true / false and the library just reverse the headers / rows / data arrays
I left it as is and I'm reversing the data in my side but if you think it's better or even needed to do it in the library side, I can create another PR

Thx alot for this i just needed it


Evaluate sharing of C code between mlkem-c-{generic, aarch64, embedded}

Right now we do have 3 copies of mostly the same C code:

https://github.com/pq-code-package/mlkem-c-generic
https://github.com/pq-code-package/mlkem-c-aarch64
https://github.com/pq-code-package/mlkem-c-embedded

In the long run, we want to share as much as possible between these C projects (and possibly additional ones). Maybe we even want to combine them into a single project at some point.
The reason for starting off with separate code bases was the different goals of the projects: In particular, the generic project wants to stay in sync with the Kyber teams reference implementation and they want to make as few changes as possible. That's why we started off our own copy and postponed the discussion of code sharing to a later point. (Since nothing has been merged into the generic project so far, I believe this was a good approach).
Code sharing between embedded and aarch64 should be easier, and we should discuss what is the best way to implement it.
Should we pull out the common code to a separate repository (e.g., mlkem-c-common) and include it into both embedded and aarch64 as a submodule? At the same time we could put in place the the checks for undefined behavious (using e.g., CBMC).
I have two thoughts about what we definitely need to consider:

For AArch64, we likely want to support multiple levels of batching Keccak permutations to make best use of hybrid scalar-vector implementations (see https://github.com/pq-code-package/mlkem-c-aarch64/issues/33, https://kannwischer.eu/papers/2022_armv8keccak.pdf). This is something we don't want/need for the embedded implementation. For now we decided to start off with a 4x Keccak API for AArch64 - you definitely don't want to allocate 4 Keccak states for the embedded implementation though.
For the embedded implementation, we do implement some stack optimizations that do change some C code significantly. For example, to avoid having to store another ciphertext in re-encryption, we have a variant of the encryption functions that compare to a reference ciphertext in-line. While this is neat when you care about stack usage, it unnecessarily complicates the code if you don't.

Partly solved by superseding mlkem-c-generic with this repository. See https://github.com/pq-code-package/tsc/issues/111 and https://github.com/pq-code-package/tsc/issues/105

Closing this for now, mlkem-generic is archived and mlkem-embedded is not very active. @mkannwischer Re-open if you disagree.


Package management

deleted virtualenv
installed os
you still need to download pipenv locally, but then to run the virtual environment the command is
" pipenv shell "

I don't think I have the permission to approve these changes, but there's nothing wrong with the code.


Support proxy contracts / ability to execute view functions on verified contracts

I was trying to view the source of a contract, but his contract uses the EIP-1967 proxy pattern, so I couldn't view the underlying logic.
There are two potential features I can think of to enable viewing of the underlying logic (which is why this issue covers two feature requests):

Natively support proxy contracts, with a separate option on hover to view the source underlying implementation. Not sure how big the scope is here since there's at least EIP-1967 and EIP-1167, and possibly others
Allow view functions to be called and if the result is an address, allow it to be actionable

Hey @mds1, thanks for the feature requests.
I am not sure if this is going to pollute the hover box too much. While I understand that for proxied contracts it might be nice to retrieve the underlying logic contract detecting this is passively (from the address without issuing a request) is not trivial. I'd like to avoid that the extension "phones out" to learn more about a contract if it is not absolutely necessary (there's kind of a privacy angle to this and I generally don't like extensions that do things without the user knowing)
I feel like you have a specific idea about an extension that would be helpful to you. Could you elaborate a bit more? (e.g. on the view feature and how this is intended to be used). The reason why I am asking is that it sounds like this could be its own extension - if it's worth the effort.

I feel like you have a specific idea about an extension that would be helpful to you. Could you elaborate a bit more? (e.g. on the view feature and how this is intended to be used). The reason why I am asking is that it sounds like this could be its own extension - if it's worth the effort.

I can see something like this being useful during both contract and frontend development/testing. Here's the use case where I'd see myself using this:

I often develop/test contracts against a forked mainnet due to their dependencies on existing contracts, so assertions are often based on mainnet values, e.g. expect(tokenBalance.mul(exchangeRate)).to.equal(someValue). When debugging to see what went wrong (e.g. am I not parsing their decimals properly, or am I reading the wrong value, or is the bug in my contract, etc.), I often head to Etherscan to read various values from various contracts. I'll copy/paste them somewhere to save them off temporarily to avoid heading back to Etherscan to pull them again later

Pretty much the same use case for frontend development, but instead of testing contract functionality this is usually for displaying information to users

phones out
I guess one can specify their own node address to connect to and avoid data leaks this way?