Button in tool details say "Back to Containers Search"

Bug Report
Viewing a tool in the tool details page, the button to go back to search says "Back to Containers Search" instead of "Back to Tools Search".
Expected behaviour
Button says "Back to Tools Search".
Actual behaviour
Button says "Back to Containers Search".
Steps to reproduce the behaviour
Tools -> Any tool
Look at top right corner.
Environment (Browser or OS and Dockstore version)
Seen in staging (v. 0.4-beta.9) and prod

solved in pull request #198


[LGA] RLP-152449

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #
Test URLs:

Before: https://main--prisma-cloud-docs--hlxsites.hlx.page/
After: https://--prisma-cloud-docs--hlxsites.hlx.page/
Worker: https://prisma-cloud-docs-production.adobeaem.workers.dev/?branch=

content reviewed and signed-off on Slack & Jira


LSC Moodlight 970743

Dear all,
I tried cloudcutter with the mentioned device, which is already in the device list. I tried the device with the script test_device_exploitable.py, which seemed to be successful. Afterwards I set up a raspberry PI 3B and tried cloud cutter. On the first view it looked good, but te device did not stop blinking, and in the end returned without exchanged keys. I add the log. Any idea what I could try?
./run_detach.sh -r <SSID> <password> wlan0 3004154-970743

Found access point name: "SmartLife-BD7C", trying to connect..
Gerät »wlan0« wurde erfolgreich mit »616c5c68-554c-4653-981a-d60245b03a91« aktiviert.
Wiping NetworkManager configs
Scanning for "A-" "Geeni-" "GRID-" "iHome-" "LDV SMART+-" "Merkury-" "Nexxt Home-" "SL-CreeLighting-" "SL-FLSNT-" "SmartLife-" "TreatLife-SL-" SSID...
Found access point name: "SmartLife-BD7C", trying to connect..
Gerät »wlan0« wurde erfolgreich mit »93bf6378-e087-44b7-a880-45a347f1ab80« aktiviert.
Wiping NetworkManager configs
Scanning for "A-" "Geeni-" "GRID-" "iHome-" "LDV SMART+-" "Merkury-" "Nexxt Home-" "SL-CreeLighting-" "SL-FLSNT-" "SmartLife-" "TreatLife-SL-" SSID...
Found access point name: "SmartLife-BD7C", trying to connect..
Gerät »wlan0« wurde erfolgreich mit »ff711d42-4dfc-4d75-b305-d9a4cc86b6bb« aktiviert.
Wiping NetworkManager configs
Scanning for "A-" "Geeni-" "GRID-" "iHome-" "LDV SMART+-" "Merkury-" "Nexxt Home-" "SL-CreeLighting-" "SL-FLSNT-" "SmartLife-" "TreatLife-SL-" SSID...
Found access point name: "SmartLife-BD7C", trying to connect..
Gerät »wlan0« wurde erfolgreich mit »106d95d4-b8f5-49e4-aa2b-3e68e92a444e« aktiviert.
Wiping NetworkManager configs
Scanning for "A-" "Geeni-" "GRID-" "iHome-" "LDV SMART+-" "Merkury-" "Nexxt Home-" "SL-CreeLighting-" "SL-FLSNT-" "SmartLife-" "TreatLife-SL-" SSID...
Found access point name: "SmartLife-BD7C", trying to connect..
Gerät »wlan0« wurde erfolgreich mit »cd6a74d9-24cc-4f61-a9e7-54760cce76c7« aktiviert.
Error, could not connect to SSID.
Failed to connect, please run this script again

I am one step further: The point is that I set the language of my PI to german, so we have to deal with german return values in common.sh:
if [ "${AP_STATUS}" != "aktiviert" ]; then
instead of
 if [ "${AP_STATUS}" != "activated" ]; then
After all, key exchanging works.
Now I would like to flash a custom firmware, and I wonder how to do.

I copied my firmware into the folder custom-firmware
I called ./run_flash.sh –r wlan0 LSC/3004154-970743 OpenBK7231N_UG_1.10.4.bin in different variations (file name only, path + filename,...).
It all ends in different error messages like

Firmware OpenBK7231N_UG_1.10.4.bin does not exist or not a file
Fehler: Gerät »–r« wurde nicht gefunden.

So, I am not sure what to enter as filename: the filename only or any path. And if a path is necessary: why does the script think the -r could be a device name... ist ist an escaping problem? Or is there any other check done, s that my OpenBeken binary is rejected.
Would be glad if anybody could help to figure out how the script works.
Thanks in advance!

Are you running elevated?  you need to run elevated for the wireless AP stuff to work.
You do not need to provide the model and file in the command.  If you don't provide them, you will be presented menus to select them instead, it will give you a list of available options.  Try that method instead?

I have switched to checking for the connected AP gateway, which is a static IP instead of a word which can be internationalized.
Other questions have been addressed in more recent commits or are unanswered/stale.  Closing this ticket.  If there are further unresolved issues, please feel free to re-open it.


Cannot change to older version of the notebook.

Environment data
Build of Visual Studio Code - Insiders: 1.60.0 -insider (user setup)
Build of python-insider: 2021.9.1121560038-dev
Build of jupyter-insider: 2021.8.2025984474
Steps to reproduce:

Open the command palette (Ctrl+Shift+P on Windows, Cmd+Shift+P on Mac)
Type 'Preferences: Open Settings (JSON)' and select the first option to open your user settings.json file Command palette
Add the following line to your user settings.json file:
"jupyter.experiments.optOutFrom": ["NativeNotebookEditor"],
If the following entry is present in your user settings.json file, delete it:
"workbench.editorAssociations": [
{
"viewType": "jupyter-notebook",
"filenamePattern": "*.ipynb"
}
]
Reload Visual Studio Code for the new settings to take effect. You should be opted back into the old Jupyter notebook interface.

Actual behavior
After change in setting.json,

This is by design. The Native Notebook editor is no longer an experiment. Sorry we didn't tell you.


Revert "Revert " Upgrade to zookeeper 3.4.14, take 4""

Reapply after needed changes in internal repo was done

Email notification arrived just now, not 5 hours ago. Strange.


Expose BuildLayout root dir from ProjectLayout

@adammurdoch wrote:
Could we also either add ProjectLayout.getRootDirectory() or ProjectLayout.getBuildLayout()? Locating a file/directory relative to the root directory from project build logic or tasks is a very common use case that is easy to break in CC and IP. For example, when redirecting the build options or locating some shared configuration file.
[The BuildLayout implementation...] should not need a Settings instance. Its root directory should be the root directory of the build, taken from the BuildLocations rather than the mutable project directory of the root project.
[...]
[NB: ] It looks like Settings.getRootDir() is doing the wrong thing, but I would just leave that unchanged and we can deprecate it later.
Originally posted by @adammurdoch in https://github.com/gradle/gradle/pull/26492#discussion_r1336430157

Probably related: https://github.com/gradle/gradle/issues/13654

Whatever solution we choose here, I think we should make IP-safe from the start

Superseded by #13654

Superseded by https://github.com/gradle/gradle/issues/13654


Feature/elb describe tags

Added resourcegroupstagging api support for ELB (classic load balancer)

Fixed linting errors, thanks! @bblommers


(maint) FreeBSD package provider improvements (pkgng)

These commits improve the pkgng provider used on FreeBSD.  The initial goal was to unbreak the mcollective_package_agent which was broken with the provider because the #query method itself was not working as expected.
While here, a few more minor improvements where introduced (unused fixtures, misnamed fixtures).

Can one of the admins verify this patch?

Ping FreeBSD puppet@ team if you want to review/comment/check/test: @xaque208 @amishHammer @tdb @Jmslagle

CLA signed by all contributors.


fix(rhino): no longer using commit top layer in update receive mode

Description & motivation
Previously, receiving in Rhino always creates a top layer with the stream, branch, and commit info, except in update mode where the received object is placed in the same layer as the object it is replacing.
Now, the top commit layer will only be created in Create receive mode.
In Update mode, objects will be placed in the layer structure as determined by the commit traversal. This means any object that is replacing an existing object in the rhino file will no longer be placed in the existing object's layer.
Fixes #1836
Changes:
Rhino Connector
Screenshots:
Before:

After (update mode):

After (create mode):

Checklist:

[ ] I have updated or added relevant documentation.

closing, opened a clean pr for 2.10


Update Composer dependencies (2024-02-23-00-10)

Visual regression test passed!
View the visual regression test report


Banned users can still execute RPC if they have stored session

Description
Banned user successfully executed RPC if they have valid stored session; There is no way to determine if user is banned via RPC API. This is extremely important if session token is set to be valid for lengthy period of time
Steps to Reproduce

Log-in via any client
Ban user you've just logged in via admin console
Execute RPC by client

Expected Result
RPC should be denied
Actual Result
RPC was executed and returned valid data
Context
Tried on Unity and Nakama 2.5.1+8216d5cc and login via device Id

Bump?

Hey @Shelim. I've added this to the development backlog for us to tackle. 👍


665 consolidate emails

Resolves #665 and #938

This looks really nice. I left a bunch of inline comments, the biggest of which is the refactoring of the two reservations controller methods (checkin_email and checkout_email) into one and the re-introduction of that functionality to our views. The only other comment I have is that I encountered an ERB warning in both _due_today.html.erb:1 and _starts_today.html.erb:1:
_starts_today.html.erb:1: warning: encountered \r in the middle of line, treated as a mere space

Not sure what that's all about, see if it's something we need to deal with. Great work!

Also note that the query for the send_upcoming_checkin_reminder task in mailmain.rake has a typo (line 6). We need to add a space at the end of the line (after and) to make it work. Since we're fixing e-mails here I think it falls within scope.

I fixed most of the issues you pointed out in the comments. I've refactored the checkin/checkout email methods, but it's failing quite a few tests so I haven't committed it yet. The parsing issues in the email bodies also have yet to be corrected.

The tests no longer fail because of the refactored send_receipt method; tests still need to be written for the new method though.

also--it seems like the \r issue is from a windows line ending character in the default messages for those two emails

Whoops, I found another issue. We broke the ReservationsHelper#manage_reservations_btn method since it relies on the Reservation#status method. We need to modify the helper conditionals so that the button shows up on reservations that start or are due today.

Also, line breaks in the app config settings are rendering improperly in the e-mail body:

Also, the checkout receipt fails when the reservation is due back today or is overdue but hasn't yet been returned (since the status is now "due today"). We might need to pass a receipt parameter into UserMailer#reservation_status_update to enforce the checked out status for those calls.
Note also that my comment above also applies to the logic determining whether or not to display the "send receipt" button.

Nice job dealing with round 1, I left a few more inline comments and found a couple more issues while manually testing out this functionality (see above). Once those are addressed you should also play around with this branch and make sure everything works as expected (all buttons / links and all rake tasks). Hopefully we can get this done in tomorrow's meeting!

okay, everything is fixed and working locally, about to force push onto this branch to fix the git issues, let's hope it works

I think this is all set?

Thanks, I'll have to review this tomorrow but hopefully we'll be able to get it in as well. What was your ultimate solution to fixing all the Git weirdness?

I made a new branch locally, merged in 938, cherrypicked from 665, then force pushed to this branch haha

Once we've dealt with validating the receipt requests, I think this should be good to go (whew).

once travis finishes this should be good!

Oh no! What's the merge conflict? In either case, you can just squash rebase, then rebase onto master to resolve it. Good work!


Add the missing enclosing div in the example of webcamAgeAndGenderRec…

…ognition.html
Hello!
I just found the missing enclosing div in one of the browser example.
Small but might be causing unexpected bugs
Thanks

Alright


[WIP]: Add linting support

Adds golangci-lint to enforce code standards.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
see 5 files with indirect coverage changes


unable to install on macos

Please provide us with the following information:

This issue is for a: (mark with an x)
- [ ] bug report -> please search issues before submitting
- [x] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

pip install azure-ai-vision does not work on macos.

Any log messages given by the failure

ERROR: Could not find a version that satisfies the requirement azure-ai-vision (from versions: none)
ERROR: No matching distribution found for azure-ai-vision

Expected/desired behavior

pip install azure-ai-vision should be installed as dependency on macos.

OS and Version?

macOS (Sonoma 14.2.1)

Versions

None

Mention any other details that might be useful
I wanted to try out the sdk for MS Odyssey but unfortunately unable to work on exercises. The lab provided on VM has bad performance.

Thanks! We'll be in touch soon.

@yb-sid are you trying to use Image Analysis or Face APIs?

Image Analysis

@yb-sid we have just released a new version of the Image Analysis SDK, which is more aligned with other Microsoft Azure SDKs. The package name also changed. Please see https://learn.microsoft.com/azure/ai-services/computer-vision/sdk/install-sdk?tabs=dotnetcli%2Cterminal%2Cwindows%2Cubuntu%2Cmaven&pivots=programming-language-python .

got it , thanks for the prompt response @dargilco


Use shortcut manager for unlinking droppable gui values

Would also probably be a good time to get rid of the extraMocks in createBasicGui()


Provides original json in Response

same as https://github.com/uakihir0/misskey4j/pull/8

ありがとうございます！


Refactor high level integration of VFX in the engine

currently all particle components / emitters are updated (simulated) at the start of the frame - which means even particles off-screen are always simulated
in order for the particle system to use few camera properties, it depends on a hacky way the forward renderer sets up _activeCamera - note that this works as expected for a single camera only
there is this comment related to this in the particle-emitter suggesting that due to not having camera during the first update (before forward renderer sets _activeCamera), and incorrect shader might need to be compiled initially .. this is fixed later when the camera changes
the emitter calls material.getShaderVariant() without any parameters, and so we don't have access to camera rendering settings (gamma, tone mapping) - workaround is used

Ideally:

This should work similarly to skinned/morphed meshes and splats, where forward renderer executes culling first, and the expensive update only takes place for the visible visuals. This should be at least case for the procedural particles where the bounds can be estimated.
user might need an option for simulate off-screen or disable

This issue reminds me a bit of gaussian splats which also have both global (shared) state and per-view state.
In the engine, meshes and materials are assumed identical in all camera views (except for shader pass and matrices) and it would be nice if we had a formal way of creating and updating per-view state.

Is there a way to tell playcanvas which is the "primary" camera in this instance?  I have a use case that may require gsplat sorting in multiple cameras, however only one of these cameras at a time will suffice in the short term.

The engine reports all cameras that the splat is visible for, and at some point if the tech allows us, we would like to sort them per camera. At the moment the code simply picks first camera, as the engine have no idea which camera is the main one. You could patch the engine and pick camera based on name or similar.
https://github.com/playcanvas/engine/blob/ac8a10f44e5abf2bdaa6c09c55f884198f457585/src/scene/gsplat/gsplat-instance.js#L219-L222
https://github.com/playcanvas/engine/blob/ac8a10f44e5abf2bdaa6c09c55f884198f457585/src/scene/gsplat/gsplat-instance.js#L179-L185
The VFX could use the same system.


Cedar Function Macros

Rendered

I've taken a pass over the whole RFC, bringing the terminology and presentation up to date with all the various discussion threads. I'm approving the current version.

Thank you @aaronjeline and @mwhicks1 for writing this RFC!
I appreciate that the current version of the proposal is simpler than the original.  In particular, by proposing macros with call-by-name semantics rather than functions with call-by-value semantics, we avoid complicating the language semantics, validation, and analysis.
Despite this, I'm not in favor of adding macros to the language at this time.  The pros don’t outweigh the cons (yet) in my opinion, and this is a major addition to the language that we cannot take back.  Macros will create a management problem for services, and they will introduce two significant sources of confusion and complexity into policies:

Bad error messages due to inlining.  Consider this example:

def foo(?a, ?b, ?c) ?c + (?a + ?b);

permit(principal,action,resource) when {
    foo(0,<PHONE_NUMBER>854775807,  2) // overflow error
};

When this policy errors at runtime, what source location should be shown as the source of the error?   Should it be the location in the macro body (?a + ?b)?  Should it be just invocation of the macro in the policy?  Some combination of the two?  The same problem applies to validation errors too.  Without good error messages, errors like this are notoriously hard to understand and debug.  And providing good error messages involves tracking source locations through macro expansions and retaining this information in this AST, and potentially EST too.   All of this is non-trivial to implement (even for the restrict macro system proposed here), and it will require non-trivial (potentially breaking) changes to the EST.

Bad performance due to hidden costs.. Right now, Cedar enjoys the nice property that the runtime cost of a policy is evident from the policy text:  it is worst-case quadratic in the size of policy text and input.  This will no longer be the case with macros. Users will need to think about the runtime cost of their policies after macro expansion.  And macros make it possible to write a policy whose actual expanded size is exponential in the size of the text written by the user.

As a pathological example, consider this macro and its application:
This policy
(2) the ability to write small policies that expand into policies that are exponentially larger than the text the user wrote.
These problems aren’t present in Cedar right now because each policy is self-contained, and its meaning and cost are evident from the text.  That’s the advantage of the lack of abstraction.  There are downsides, of course, as outlined in this RFC.  In my view, we are yet to see compelling evidence that abstraction provides enough benefits in a very restricted authorization DSL like Cedar to justify the added complexity.  For that reason, I’m voting against accepting the RFC at this time.

Thanks for providing this carefully thought-out critique! I am still optimistic that macros are a net win. Here are some responses.

Bad error messages due to inlining.

This seems like a surmountable problem. I presume there is much we can learn from far more interesting macro systems' handling of errors. Off the top of my head:
For run-time evaluation, you don't have to in-line the call in advance, you can in-line by creating the expression on the fly, while evaluating, basically resulting in a call-by-name function call. The in-lined body can include source locations that reflect the macro body in the right places, and the macro args in the others. The error message can include a stack trace, which a user might expect. It should be possible to prove (or test) that that doing this is equivalent to in-advance in-lining. For validation, I think you can do a similar thing.
For Lean models, obviously you don't need to track the source locations. You don't even need to do on-the-fly inlining, at least at first, by relying on DRT against the Rust, and PBT within the Rust, to show equivalence. We can prove equivalence in Lean later, if we wish.

Bad performance due to hidden costs.

This is a fair point, and I worried about this, too. Here are some mitigating factors that come to mind:

Services are welcome to impose bounds based on the in-lined policy size, rather than the concrete policy size. Users can be made aware that this is the case, in which case both users and services benefit: Policies are more compact when stored (and read), even if they are larger when evaluated. We could imagine warning users, with a policy linter, if they stray into pathological territory.
In-lining on the fly, during evaluation, should help mitigate maximum in-memory size, in some cases at least.

Ultimately, I feel that the readability and reusability benefits of macros are significant; the increase in complexity to support them is small; and that we are failing to solve the problem posed by today's extension functions if we do not provide them. Yes, we cannot stop users from using them in unwise ways, but that's true in general. We can guide them with linting, documentation, etc. toward good solutions.

Can you say more about how on-the-fly macro expansion would work?
The way I imagine it would work means we’d have to break the is_authorized API (among other breaking changes).  So, is_authorized would have to take an extra environment argument, which is a binding from macro names to their bodies. The evaluator would use this environment to inline macro arguments into macro bodies on the fly.  (Actually, I think the evaluator might have to expand the arguments before inlining them, for hygiene.)
In addition to breaking the API, we’d also have to extend the AST (and possibly break the EST), at least in Rust.
Doing macro expansion statically, prior to evaluation, avoids the above problems, but has the issue that constructing useful error messages becomes hard.
As for Lean, formalizing function calls (CBV or CBN) is possible but tricky.  For example, it will be non-trivial to prove termination (because the size of the AST won’t be usable as a natural decreasing measure during recursive calls). If we want to formalize this, we’ll definitely want to keep the alternative formalization separate from the core semantics / validation / analysis formalization, because we don’t want to handle on-the-fly inlining in these more complicated components too.
So, we would need an additional concrete semantics for Cedar, with macros and CBN semantics, and a proof that this alternative semantics is equivalent to our existing semantics post-expansion.
This all adds a hefty engineering and maintenance burden.  My concern continues to be that this burden as well as the potential confusion / usability / performance issues are not offset by the upsides of macros for Cedar, at least from I’ve seen so far.
How to weigh these tradeoffs is, of course, subjective, and I realize that mine is a minority opinion :)

The way I imagine it would work means we’d have to break the is_authorized API (among other breaking changes). So, is_authorized would have to take an extra environment argument, which is a binding from macro names to their bodies. The evaluator would use this environment to inline macro arguments into macro bodies on the fly. (Actually, I think the evaluator might have to expand the arguments before inlining them, for hygiene.)

I'm not sure there would be much API breakage. The environment argument could be wholly contained within the PolicySet object, which would make sense as that's already the result of parsing. Beyond that it seems like everything else is just an expansion of the API.
The error messages problem seems like the most important to solve. As far as the problem around where the source is located, services already have to solve this is the hold cedar policies as separate entities instead of one blob of a policyset.

5. Are type annotations required or optional?

I'd make them required at the beginning. We can relax the rule in the future.

This raises two issues:

This feels weird if you aren't using a schema at all
This gives you no way to write polymorphic functions unless we extend the type annotations with parametric polymoprhism (which seems like a log)

Are type annotations required or optional?

I'd make them required at the beginning. We can relax the rule in the future.

This raises two issues:

This feels weird if you aren't using a schema at all
This gives you no way to write polymorphic functions unless we extend the type annotations with parametric polymoprhism (which seems like a log)

Except almost everyone should be using schemas. So.. :)

Comments from Dan Wang (who doesn't have a GitHub account), plus my responses:

I would consider not calling this concept a macro or using the def syntax. Theorem provers have the concept of abbreviation. For which the proposal smells more like. Lean has a similar concept. I find the call by name conversation a bit confusing to. To me this just "expand the parse tree".

Abbreviations in Twelf, per the link, look like type abbreviations, not term-level functions. They don't seem to have parameters. In Lean, an "abbreviation" seems to be a non-unicode way of specifying a unicode character.
It is call-by-name in the sense that you can really do the calls on the fly, rather than all in advance, as an evaluation strategy.

The fact these cannot refer to other macros is a bit confusing. There very second class nature, make me want to make their invocation standout with a similar to the rusts "!" convention.

The double(double(..) example shows that even without non-recursive-self-reference you have blowup, so why not allow macros to refer to other macros?

consider some name other than macro.
make the call of these things standout (aka don't treat them like normal function calls.. because they are not)
remove self-reference restriction to make them more powerful.

It's a fair point that even without self-calls there is an opportunity for bad behavior, and thus we might relax that. Our thinking was that we can add internal calls later, if customers demand it. But maybe we should consider it now.

I assume a debugging aid there will be a mode to see the fully expanded view of the code

That seems reasonable.

Abbreviations in Twelf, per the link, look like type abbreviations, not term-level functions. They don't seem to have parameters. In Lean, an "abbreviation" seems to be a non-unicode way of specifying a unicode character.

Lean abbrev is more powerful than that.  It can be used to define type abbreviations but it can also be used to define function-like macros.  Something like:
abbrev foo (v : Nat) : Nat := 1 + v

Hi, I did some thinking here with a few folks, just some observations:

This would begin a journey into having a fully featured Cedar "programming" language.  I could imagine it would be very useful to be able to define constants and even types with macro-methods on them.  At that point, I'd also want to be able to define packages, so I wouldn't always be populating a global namespace anytime I used these features.

Related to 1, a Cedar policy is currently just a list of policy statements.  This change would be a notable departure from that, as now a Cedar policy would be not only policy statements, but whatever macros, etc, are also in the document.  So a tradeoff is made in terms of understandability - you have to understand more language features, but your policy statements could become more terse.

I could also see accomplishing all the same stuff through a non-Cedar templating language of choice.  This would keep the core Cedar be just policy, and leave the meta-templating outside the scope of Cedar.  The drawback here, being you'd have to learn Cedar and whatever your templating language is.

In any case, I really liked some of the comments / notes in the RFC such as:

Wanting to keep performance provable
Wanting to avoid user-made extensions because they could have non-deterministic results which breaks the ability to re-play a decision
The use of the word macro seems better than function for what these are

In the Go implementation, I think adding user-made extensions wouldn't be terribly difficult, but the concerns about breaking the analyzability / determinism give me pause to think.

Similar concerns are already present in comments, but:

Is this problem not adequately solved by external templating today?
Is this the right part of the cedar ecosystem to insert macros?
2a. Given this introduces the ability to define the same macro twice, presumably causing an error, then without a packaging system this makes macros unusable once you reach a large enough mass of cedar policy. Schemas already exist to contain these kinds of unique identifiers.
Philosophically is cedar the place where users spend their time and define their logic (constants, packages and scopes, functions) or is cedar a data format for the result of higher-level language? Currently Cedar is trivial to understand because everything can be interpreted in the same way: forbid or permit according to these rules. From an auditing perspective cedar is thus an ideal, if verbose, format for expressing exactly what is and is not allowed. Adding macros within cedar itself adds a layer of indirection to cedar's auditability; if Cedar is eventually going to become something like a Turing complete programming language, that seems appropriate, but I'd appreciate an intentional decision stating that intended direction.

Thank you @philhassey and @200sc for the comments!
My take is along the same lines:  I want all the abstraction in a general purpose language :) but not necessarily in a DSL like Cedar, for the reasons mentioned in the discussion and in your comments.
To answer the last point raised by @200sc:  Cedar won't become Turing complete.  Analyzability is a key tenet of the design.
It is worth noting that macros won't compromise logical analyzability---that is, the ability to mechanically reason about policy behavior by reducing its semantics to a logical formula.  But they can hurt understandability as much as they help, as all abstractions do.
In my view, the upsides of abstraction (terseness and expression reuse) are not worth the added complexity for policy writers, readers, services and applications, and implementors of Cedar.

Hi @mwhicks1 - just to clarify my statement:

I could imagine it would be very useful to be able to define constants and even types with macro-methods on them. At that point, I'd also want to be able to define packages, so I wouldn't always be populating a global namespace anytime I used these features.

I'm not objecting in general, but I am saying "if we do this, we'll want a few more things".   Which relates well to your comment:

But I don’t feel that we need a package system before introducing macros. It can be a fast-follow.

I feel the same way about adding in constants, and types with macro-methods.  At which point Cedar would be a much richer language.  I do think it's reasonable at this point to consider if that's where we want to end up though.  I'm not sure.

Responding to various comments:
From @philhassey

In the Go implementation, I think adding user-made extensions wouldn't be terribly difficult, but the concerns about breaking the analyzability / determinism give me pause to think.

Even worse, it's another step where we need to make sure we have the exact same behavior between the Rust and the Go, since they won't be able to share this code easily. While this is also true of the macro system, it's not true of each individual macro.
From @200sc

Is this problem not adequately solved by external templating today?
No, as A) template holes can only be ?principal and ?resource, and even if we relax that restriction, template holes can't take arguments.

Given this introduces the ability to define the same macro twice, presumably causing an error, then without a packaging system this makes macros unusable once you reach a large enough mass of cedar policy.
Not disagreeing with the general point, however the proposal as stated now does allow for namespacing your macros.

Adding my two cents: I'm inclined to "no".
It puts a huge burden on services built around Cedar. To keep up with Cedar releases, these parties need to schedule a large engineering project for storing these fragments and utilizing them efficiently. If they don't, they fall behind the language treadmill. Or, we end up with a bunch of opt-in features for Cedar such that when someone says they are "Cedar compliant", nobody knows what that means until they read the matrix of opt-in features within the service documentation.
We also have audiences who are already concerned that Cedar may be growing too complex when their customers are trying to achieve simple things. Evolving Cedar toward something that starts looking like a full-fledged programming language is a slippery slope that runs a real risk of turning away these audiences.
I'm sympathetic to the goals, and agree with other comments that audiences could use their favorite standard templating language and preprocess the Cedar themselves. And, I wouldn't be adverse to vendors supporting this feature on their own timelines, as an extension. Or, even for Cedar to suggest a common approach to this.
I also noted this discussion began with a request for a "Semver" extension, which I'm also sympathetic too. Somewhat ironically, I'm wondering if it would have been faster to just implement "Semver"!

to keep up with Cedar releases, these parties need to schedule a large engineering project for storing these fragments and utilizing them efficiently

This is a good point, and suggests what others are saying about needing a higher bar for requests from users

I'm sympathetic to the goals, and agree with other comments that audiences could use their favorite standard templating language and preprocess the Cedar themselves. And, I wouldn't be adverse to vendors supporting this feature on their own timelines, as an extension

I disagree with this for two reasons:

Having each service implement their own templating feature means they won't be compatible, you can't easily move between them. If people come to expect a templating feature, then you still have to solve the all the service-oriented problems around storing/retrieiving functions. In the worst case, we evolve towards an ad-hoc, poorly specified standard instead of an intentionally thought out one. (Regardless of it's this RFC or another shot at it). It won't be able to integrate with features like Cedar namespaces or a potential future module system, so that will also be left for service owners to figure our ad-hoc.

Text based templates are fundamentally the wrong tool for working with Cedar policies. Cedar policies are not linear sequences of characters, they are trees. A generic templating tool such as the C preprocessor is not able to reason about the actual structures users are manipulating, just the text based shadow of it. In the current proposal for example: every macro invocation is guaranteed to produce a valid cedar expression. It's fairly trivial to extend the current proposal to allow for type checking over macro functions in isolation. These two things are impossible for the text-based case. If we worry about the cognitive complexity of reading policies with macro invocations (a fair concern!) then the overhead of reading policies with arbitrary text substitutions is going to be worse and easier to mess up.

for Cedar to suggest a common approach to this.
I think if we want to suggest a common approach to this, it should be something like this RFC.

I also noted this discussion began with a request for a "Semver" extension, which I'm also sympathetic too. Somewhat ironically, I'm wondering if it would have been faster to just implement "Semver"!

To address this last point: We didn't just implement SemVer because doing so has maintenance costs which don't scale well. Each extension function we add increases the testing, validation, analysis, etc. burden of core Cedar. Instead, we wanted to explore a single mechanism that addresses them in one fell swoop. This is more scalable on the core Cedar team, and gives more agency to Cedar users.
I am still bullish that what's proposed here is the right thing to do. But I also appreciate the words of caution. The right course is to gather more information about uses/needs, and to think about open questions like packaging/management of macro definitions (which still aren't solved by the current extension function mechanism, even if we thought that was the right approach instead).
One thought: Could we add Cedar macros as an experimental feature, and let customers use it and report back?

Chiming in here to substantially agree with @aaronjeline and @mwhicks1, particularly their most recent two comments each.  I think it would be a big mistake to encourage folks to use "standard" templating languages on top of Cedar, instead of building something like this RFC, which can enforce Cedar macro hygiene, syntax checking, etc etc.  To the extent that one of the concerns raised in comments here is that this feature increases the cognitive complexity of Cedar : using a general-purpose templating language on top of Cedar would be even worse in terms of cognitive complexity, and wouldn't integrate with Cedar validation and analysis, like the macros in this proposal would.

wouldn't integrate with Cedar validation and analysis, like the macros in this proposal would.

Can you explain what you mean by integration?
If an external templating system simply expands whatever the user writes into a Cedar policy, the analysis will handle the expanded policy fine and so will validation.
It’s worth noting that custom macros don’t provide any advantage for analysis, which would have to inline every invocation of the macro in order to capture its semantics at the invocation point.  (That’s how we handle extension functions too—the definition is inlined at the call site, after appropriate sequencing of argument evaluation to account for errors.)
In this proposal specifically, macros aren’t helping with validation either, because they aren’t typed and cannot be type checked independently of call sites.  We could consider writing a type inference algorithm that infers types for the polymorphic macros, but that’s another big endeavor, source of complexity, and engineering burden.
An advantage that this proposal has over an external templating system is the potential for better error messages, because a custom macro system (like this one) could propagate source location information through expansion.
Still, I strongly urge caution here, and specifically, not underestimating the burden that this feature imposes on users, services, and language implementers.
If I had to take a guess at the implementation and maintenance burden for Cedar alone, I would say we’re looking at an additional ~10K LOC, including the Rust implementation (with proper expansion tracking, error messages, etc), Lean model and proof (by having a parallel semantics with CBN and proving it equivalent to the core semantics after expansion), and diff testing.
We need to be really sure that this is the right direction for Cedar before proceeding, and not just because of the engineering burden.
In my view, this is not the right direction from a language design point of view either.  As several other commenters noted, this would push Cedar toward looking more like a general-purpose language.  And that’s a slippery slope, which inevitably leads to more complexity and feature creep.

Can you say what you mean by integration?

syntax highlighting, autocomplete, hover tooltips, potential for type annotations, using the cedar namespace system, using whatever stdlib mechanism we may decide on, checking if a macro is a valid expression, rendering the macro as an EST, runtime errors that track proper source locations, type checking errors that track proper source locations, anything that requires parsing or thinking about the macro in isolation becomes impossible in the "generic template" system answer.

As several other commenters noted, this would push Cedar toward looking more like a general-purpose language. And that’s a slippery slope, which inevitably leads to more complexity and feature creep.

This feels like a very ill-defined argument. We still have the guardrail of analysis preventing us from expanding. This adds no expressive power to the language. Templates did not meet this criticism, were we wrong to miss it there? Action groups likewise. Surely opening of the extension mechanism so users can easily share extensions would hit this bar. I'm not saying it's an incorrect argument, it just feels vague.
I think there's three arguments happening here, and I'll try to distill them.

This feature is both a large implementation lift and are large conceptual addition to the language. We have not met the bar of evidence that users want this feature to even begin to consider it.

This is fine. I may personally disagree, but I'm ok with declining for now and seeing if more evidence accumulates. If that evidence ends up accumulating, we could potentially revive this RFC or consider a different mechanism for the same goal. If it doesn't, we won't.

We think users will want this feature, but we don't want to own it (for the reasons above), so we should recommend they use an external template system.

This feels very wrong to me. For all the reasons I've described above. I'll add one more here. If a macro system within cedar brings it to close to a general purpose languages, why does a recommended macro system outside of cedar not do that? Again, operationally,  you have all the same concerns. Semantically/readability wise, you have all the same concerns except with less guadrails. Is there an existing macro system that we can show as an example that more readable than this proposal is? Standards wise it's a mess. If we know people want this feature, and the feature is feasible, then it feels weird to recommend what is essentially a workaround.

Regardless of whether people want this feature, we shouldn't do it because we believe abstraction mechanisms like this one don't belong in Cedar. In this world, we also don't recommend using external templating systems, because we think reading/writing cedar policies in terms of a context of non-locally-defined substitutions is not a good idea.

Obviously I disagree (I wrote the RFC :D ), but there's probably more to talk about here.

The more I think about this feature, the more torn on it I become. I see value it provides in streamlining policies and reducing duplication. On another hand, introducing brand new standalone concepts like these macros feels a bit heavy handed, with implications for integrated services.
May I share an idea to get some feedback on it?
Extension methods in C# inspired this approach. Basically, we'd allow users to define their own type extensions in schema directly. Semver example could then look like this:
// Schema declaration
type SemVer = {
	major: Long,
	minor: Long,
	patch: Long,
	greaterThan(?other: SemVer): {
		if this.major == ?other.major then
			if this.minor == ?other.minor then
				this.patch > ?other.patch
			else
				this.minor > ?other.minor
		else
			this.major > ?other.major
	}
}

// Use in policy
// Permit access when the api is greater than 2.1
permit (principal, action == Action::"someAction", resource)
when {
    resource.apiVersion.greaterThan({ major: 2, minor: 1, patch: 0 })
};

I understand that this goes against one of our tenets that schema is not supposed to affect authorization outcome. But I also feel like we've taken incremental steps to relax that stance with schema-based parsing of the request data and schema-based validation of the request.

Thanks @aaronjeline for summarizing the three arguments!  That's really helpful.  I'm in camps (1) and (3), and below, I'll try to explain why this RFC is triggering my spidey sense, with the full acknowledgement that this opinion is biased (informed? :D) by my own programming experience (Racket, Lean, and a long time ago, Java) and design preferences (minimalist).

This feature is both a large implementation lift and are large conceptual addition to the language. We have not met the bar of evidence that users want this feature to even begin to consider it.

I believe this is true.  We haven't had any users (that I know of) ask for this feature.  We have had many users ask for all other features that have required this level of engineering effort (e.g., partial evaluation).
We have also not considered a feature that departs this much from the original language design, which focuses on simplicity and "what you see is what you get" behavior.  This focus is lost with no gain in expressiveness and with minor (in my eyes) gain in convenience. It is worth noting that this RFC doesn't solve the problem that originally inspired it, SemVer comparison, because the original ask was for the comparison function to provide a similar API to decimals and IP addresses, which requires writing an extension function to parse SemVer strings.
The effects of supporting this feature are wide-ranging and global.  This feature is not only an engineering lift for us, but also for all applications and services that use Cedar.  We would be forcing them to deal with macro storage, management, distribution, and updates---or risk falling behind the language treadmill as @D-McAdams's comment explains.  Services and applications are our main customers, even more so than individual policy writers, and I would want to see at least 5 services / applications actively advocate for this feature before adding it to the language (borrowing 5 from @andrewmwells-amazon's comment).

Regardless of whether people want this feature, we shouldn't do it because we believe abstraction mechanisms like this one don't belong in Cedar. In this world, we also don't recommend using external templating systems, because we think reading/writing cedar policies in terms of a context of non-locally-defined substitutions is not a good idea.

I believe this is true as well, and the following is going to stray a bit into subjective preferences and design philosophy, so please bear with me :)
Cedar is not a general-purpose language, and it was designed explicitly to be analyzable and simple.  The current proposal is to add a feature to the language that is extremely limited (for good reasons), and not really capable of letting you build real abstractions---which are built through composition.  Cedar macros cannot call other macros (for good reasons).  They are not real CBV functions (for good reasons), which is what most programmers expect from functions.  They are also a very weak syntactic abstraction (for good reasons), because they are lacking all the features you find in powerful macro systems (such as Racket or Lean).  In other words, they land us in the uncanny valley of language design (in my eyes), where Cedar looks sort-of general purpose without actually being so.  This then creates the expectation of even more features you find in a general purpose language (as noted by @philhassey):  global constants, module system, packaging system, etc.  And that lands us in a state where Cedar is not beautiful (again, in my eyes) either through simplicity or power.
I cannot think of any popular, simple, standalone DSLs that have things like macros, modules, packages, etc.  (I can think of some that do have these features but are considered complex, and are well out of bounds of what is analyzable.)  This is likely my own blind spot, and I'd be super curious if someone can point me at some DSLs where this has been done well, where it's considered simple and ergonomic, and that we should emulate :)
Cedar is not used like most programming languages.  Most programming languages are file-oriented; people write a single conceptual unit (application) that is thousands of lines of interconnected code; and in that world, things like modules and abstractions are absolutely essential.  While some people may use Cedar by putting all policies in a single file, that is not the case for a large number of users who interact with Cedar through a service or an application.  Here, we see two modes of use:  a (relatively!) small number of static policies, or a small number of templates with thousands of instantiation.  In both cases, the actual logical unit (the authz model) is not thousands of lines of hand-written Cedar code, and in my view, macros or other heavyweight abstraction mechanism are not needed to build and maintain this logical unit.
Finally, thank you all for a really great discussion.  I've found it immensely helpful in crystallizing my own understanding of my gut reaction :))


Enzyme >= 0.12 compatibility

With Enzyme v0.12 a few changes have been made to autodiff which are partly exposed to ParallelStencil. In this PR we wrap the necessary args to Const, add the necessary arg that checks if there is a returned value (in the test case there is Nothing -> Const).
Co-authored by Valentin Churavy  during the Hackathon

Thanks for the PR! Indeed, the CI for another reason: https://github.com/JuliaGPU/AMDGPU.jl/issues/685
I will merge and therefore anyways.


bug in quickstart?

Output of: "./mox quickstart<EMAIL_ADDRESS>for mox v0.0.8 binary contained instructions but then switched without warning to config:
...
Configuration files have been written to config/mox.conf and
config/domains.conf. You should review them. Then create the DNS records below.
You can also skip creating the DNS records and start mox immediately. The admin
interface can show these same records, and has a page to check they have been
configured correctly.
; Time To Live of 5 minutes, may be recognized if importing as a zone file.
; Once your setup is working, you may want to increase the TTL.
$TTL 300
; DANE: These records indicate that a remote mail server trying to deliver email
...

"switch without warning to config" is the DNS records right? The lines starting with ";".
Those are in DNS zone file syntax. And the line "Then create the DNS records below" is supposed to introduce them. But The two sentences afterwards continue with prose. Perhaps it's clearer if that paragraph ends with something like: "Add the following DNS records to your DNS zone file, or add them through your DNS operator web interface: "?
Or perhaps I'm misunderstanding the issue.

Yes that's exactly the issue, thanks, I didn't recognize the format, so the clarification you propose would have helped.

Excellent, thanks for reporting. I'm closing the issue. Feel free to reopen if needed.


InfoWindowTemplate implementation throws error using Xamarin Forms 3.5

Hi,
It appears there is a breaking change sometime after Xamarin.Forms 3.1 that causes the InfoWindowTemplate implementation to throw an exception due to mismatched XF versions when you click on an annotation marker on the map.
An update of the Naxam.Mapbox.Forms  to the latest XF version resolves the issue, apart from an exception reading the platform in one method in the iOS project which is an unused variable anyway.
Cheers
rj

Hi,
InforWindow is being depreciated from Mapbox Android. We completely removed it for Android implementation even the property is still there.
Alternative solution not implemented yet.
Cheers.


Bump up game version to 1.8 + a few more reliability related changes

I've updated the way it changes GC settings - now there is a single method doing this. In addition, it updates these settings only when they differ with the current ones (potentially fewer calls to GCModeChanged event handler -> fewer retries).
Finally, I've added some logging, so it is possible now to confirm whether all of this works or not by starting Beat Saber with "--verbose" option.

Oh, and the last thing: .csproj file format changed to the latest one.

I haven't updated this mod myself as I no longer need it since the game uses incremental garbage collection now. I heard someone say it doesn't seem to do anything on this version.  I'd suggest checking if the mod is actually doing anything by monitoring the number of collections throughout a song. If it's working there shouldn't be any (with off during gameplay on of course).

Hi, looks like this PR is obsolete now - later I figured out these settings don't work with incremental GC, + ended up writing https://github.com/alexyakunin/BeatSaberLagKiller which tries to trigger incremental GC manually.


[5.9] Add support for the copy operator and fix parsing issues around consume

I will add the CCC later.

apple/swift#66032 is the swift 5.9 commit.

https://github.com/apple/swift/pull/66032
@swift-ci test

MacOS test failure is due to a slight difference in enablement flags on 5.9 vs main:
/home/build-user/swift/test/Sema/copy_expr_noimplicit_copy.swift:8:3: error: unexpected error produced: Can not use feature when experimental move only is disabled! Pass the frontend flag -enable-experimental-move-only to swift to enable the usage of this language feature
@_noImplicitCopy let x = Klass()
^
I just fixed that in the other PR

https://github.com/apple/swift/pull/66032
@swift-ci test

https://github.com/apple/swift/pull/66032
@swift-ci test


SpriteSheetUtils.extractFrame has not loaded.

Hi, I'm using "SpriteSheetUtils.extractFrame" to extract a frame from the atlas. The problem is that the image has not had time to load and therefore does not have a width and height property when trying to access it.
SpriteSheetUtils.extractFrame = function(spriteSheet, frame) {
    if (isNaN(frame)) {
        frame = spriteSheet.getAnimation(frame).frames[0];
    }
    var data = spriteSheet.getFrame(frame);
    if (!data) { return null; }
    var r = data.rect;
    var canvas = SpriteSheetUtils._workingCanvas;
    canvas.width = r.width;
    canvas.height = r.height;
    SpriteSheetUtils._workingContext.drawImage(data.image, r.x, r.y, r.width, r.height, 0, 0, r.width, r.height);
    var img = new Image();
    img.src = canvas.toDataURL("image/png");
    return img;
}

Could the image have and "onload" event to make sure it is loade before it is returned?

Yes, unfortunately we can't delay the return until the image is loaded (if you had animation running it would cause a very noticeable pause). You'll have to monitor the .complete and .onload.
As an important note: If you're displaying the frame in EaselJS, it's always faster to use a Sprite to display the frame than to extract the frame. One place where you might use extractFrame is for using it with a bitmap fill.

So would it be okay to use this method to create alphamapfilters for specific frames in a spritesheet?


Update gelf.go

wrong chunkCountInt when length%chunksize == 0

thank you for your contribution! :)
one minor thing: can you add a test?

ok, test is done

Is there any other problem? @robertkowalski

sorry for the delay! no there is no problem, I was just 14 days on
vacations and also my computer broke!
will merge tomorrow when my machine is repaired.
On Wed, Nov 4, 2015 at 1:01 PM, lintianzhi<EMAIL_ADDRESS>wrote:

Is there any other problem? @robertkowalski
https://github.com/robertkowalski
—
Reply to this email directly or view it on GitHub
https://github.com/robertkowalski/graylog-golang/pull/2#issuecomment-153700229
.

+1 merge it after squashing / rebase :)

rebased

+1 merge it :)


Create Dataset/Model Frontend page

It is essential to include the dynamic possibility of create Author/Task and other elements dynamically in the same page


increase default network timeout

Please fill in the fields below to submit a pull request.  The more information
that is provided, the better.
Fixes #2442
Description of the changes being introduced by the pull request:
increase default network timeout from 4 sec to 30 sec.
Please verify and check that the pull request fulfills the following
requirements:

[x] The code follows the Code Style Guidelines
[ ] Tests have been added for the bug fix or new feature
[ ] Docs have been added for the bug fix or new feature

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 97.803%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1358

Relevant Lines:
1381

💛  - Coveralls

Hey @jku , can you take a look at this PR when you get a chance? thanks

Works for me. AFAICS, we already acknowledged the problems with and the resulting lack of slow retrieval protection (#932). So I don't think this patch has any real security implications.
@NicholasTanz, can you please address @jku's comments? Happy to then approve.

Works for me. AFAICS, we already acknowledged the problems with and the resulting lack of slow retrieval protection (#932). So I don't think this patch has any real security implications.
@NicholasTanz, can you please address @jku's comments? Happy to then approve.

yes, just made the changes @lukpueh


Benchmark icon-button and icon-button-toggle

Copied from @e111077's idea from https://github.com/material-components/material-components-web-components/pull/370#pullrequestreview-275633641

Closing for #617


Updating status for CSS Grid in Safari TP

CSS Grid is now enabled by default in Safari Technical Preview.
There is still a setting in the drop-down menu where people can toggle it on and off, but if you install Safari TP fresh from a download, it's now on.

In the first commit for this pull request, I removed entirely the footnote about turning Grid on in Safari TP. In the second commit I put the note back, altered for the new reality. I'm not sure which way you want to do it. So here're both options.


Add search and search_all attributes

Description
This PR introduces two new methods:

search: Returns the search results for a dataset search query.
search_all: Returns a generator that yields pages of search results.

Type of change
Please delete options that are not relevant.

[X] New feature (non-breaking change which adds functionality)

How has this change been tested, please provide a testcase or example of how you tested the change?
You can test this feature using the following code:
import roboflow

roboflow.login()

rf = roboflow.Roboflow()

# List all projects for your workspace
workspace = rf.workspace()

project = rf.project("mug-detector-23eqf")

# List all versions of a specific project
print(project.search(
    prompt="mug"
))

records = []

for page in project.search_all(
    prompt="mug"
):
    records.extend(page)

print(len(records))

You will need to specify your own dataset ID.
Any specific deployment considerations
N/A
Docs
I will update our quickstart docs on Gitbook once we release this feature.

Be sure to make style

Done!

Let me know when you get the chance to release this in the pip package!


Phinx Export Feature

It would be nice to run phinx --export to export a json/xml/SQL representation of your database migrations. What purpose would this serve though?

+1 It would help me to get a nice solution for this problem: http://stackoverflow.com/questions/28792430/workflow-with-database-create-alter-and-drop-commands-and-web-applications-in-pr

After a few months, we clear out our migrations. After a year and 5 developers, we had well over 200 migrations. And that was from a DB that was NOT phinx controlled. When we deploy a feature branch, we clear out the migrations and rebuild our base install.sql. We also have a preset set of data which is retrieved from the live DB so that a new developer gets a decent clean set of data and a completed DB schema.
Having a standardised approach (one which we can expand upon to include our specifics) would be a great feature.

+1 would be helpful for someone who needs to review/debug migrations. Also it would support executing queries on another machine without phinx.

+1 for export feature to compact big list of migrations in long project.
+1 running automation tools became faster, running 1 sql file rather then all migrations
As extra will be nice to have first migration generation from existing database. As phinx is really useful in custom projects, others frameworks already have database migrations and seeding. But custom projects usualy already have database and its regular monky job converting sql to phinx

What about a way to reconcile the files down to minimal creates and updates. Meaning if a table is created in one migration, then updated in another, to be able to reconcile this down to one file that has a create? I can see this not being quite so simple, especially if there are multiple things happening in one migration, but it still would be a nice to have.
Another plus might be to have the files generated into subdirectories by year/month so that there aren't so many files in one directory. Right now my company is up to 834 files in almost 2 years.

:+1:

+1 on that

+1 In fact missing of this feature makes me hesitate of adding phinx into my project.

Plain SQL is easy to review and be inspected on in troubleshooting.
Less dependency, i.e. phinx, less moving parts in automated deployment.

+1

@foalford Phinx is amazing, don't let that missing feature stop you from using it.

Well thanks for caring. Initially I was trying to see if it's worth of contributing my code. Before doing that, I found liquibase, which quite fit into my needs. Also I think that it is a good competitor for phinx.

#1127 SQL Dump option has now been merged. If JSON / XML dump is still a requirement, please create a new issue, as this has aged.


Python3 compatibility

Edit script for 2.7, 3.4, and 3.6 compatibility
What changed: print statements and dict iteritems() had to be refactored, docs edited.
What also changed: the divider lines were reduced, both for PEP8 reasons, but also so it displays better on smaller CLI windows.

Sorry for taking so long to get around to accepting this. I tested that the script was still working in these versions of Python:

2.7.10
3.6.1

Thanks!


min max issue

Hi,
Assume I have a 1024-element vector, is there any way for me to find out the maximum number of this vector? And further more, the index of this maximum number?
BR

Are these elements real numbers, floating-point numbers, or integers? What is the range of these elements?

I'm finding solutions for investigation.
are they all possible?
for example, for floating-point numbers, and uncertian number of elements for a vector.
BR

It's expansive to evaluate comparison. The straightforward solution is to create a look-up table (BFV/BGV). An alternative solution is approximating comparison with a polynomial (CKKS).

It's expansive to evaluate comparison. The straightforward solution is to create a look-up table (BFV/BGV). An alternative solution is approximating comparison with a polynomial (CKKS).

so any examples of these using SEAL?
BR

It's expansive to evaluate comparison. The straightforward solution is to create a look-up table (BFV/BGV). An alternative solution is approximating comparison with a polynomial (CKKS).

So doe this mean , there's no direct way to use SEAL to implement the min or max of a 4096-element float64 array by calling one or two functions, right?
And what do you mean by approximating comparison with a polynomial (CKKS) when the case is to get min or max of a vector?
BR

It's expansive to evaluate comparison. The straightforward solution is to create a look-up table (BFV/BGV). An alternative solution is approximating comparison with a polynomial (CKKS).

so any examples of these using SEAL?
BR

In BFV/BGV, you can perform equality check. To achieve comparison, you have to do a look up table like this:
// Return true if a > b.
if (a == 0 && b == 0) return false;
else if (a == 0 && b == 1) return false;
else if (a == 1 && b == 0) return true;
else if (a == 1 && b == 1) return false;
else throw invalid_argument("a and b must be 0 or 1");

With CKKS, how do you express a function a > b ? true : false with additions and multiplications of floating point numbers? This paper shows a way to approximate.

@WeiDaiWD  Do you know any github repository that has already implement the CKKS comparison based on the SEAL library?  Thank you!

@WeiDaiWD Do you know any github repository that has already implement the CKKS comparison based on the SEAL library? Thank you!

I don't have a specific one in mind. There have been many papers that used Microsoft SEAL to implement ReLU function which requires a simulation of comparison. They might have some code available. Just a direction.


Initial support for the Go language server (gopls)

Pretty simple stuff at the moment. Spent a lot of time tinkering with it on windows (non WSL2), the workdir volume mounts so not work quite right there. I would like to experiment more with windows support outside of WSL2, but this works fine in WSL2 right now.
One issue I've run into is that if you're outside of your go modules directory and open the file it's going to use the cwd you're in, not where the file is located, so gopls will throw errors. I believe that's just something that will be handled as the system matures naturally though.

Fixed merge conflict and good to go!


Console Error Cleanup part deux!

@kubabutkiewicz , can you post a comment on this issue for what you propose the second batch of console errors should be so that I can copy/paste it into the OP?  Here's the comment from the OG issue

https://github.com/Expensify/App/issues/51099#issuecomment-2447955053

There are 18 open issues with 'console error' in 'em ,  which ones or batch of ones do you propose we prioritize to fix next @kubabutkiewicz

Hello, Im Jakub from Callstack and would like to help with this issue

@mallenexpensify Yeah, I will go through those issue today and will post a massage about which ones we will handle in that issue 😄

@mallenexpensify I went through issues from your comment and this is my thoughts:

https://github.com/Expensify/App/issues/53547 - this seems to be normal bug and we shouldn't tackle it in that issue
https://github.com/Expensify/App/issues/53547 and https://github.com/Expensify/App/issues/52969 are the same so we can close one of them and tackle it here
https://github.com/Expensify/App/issues/53390 this seems to be normal bug and I don't see any console errors here
https://github.com/Expensify/App/issues/53045 console error here its the same as above so we will tackle it here
https://github.com/Expensify/App/issues/52673 this also seems to be just a bug and error in the console its related to that bug
https://github.com/Expensify/App/issues/52472 going through that issue I dont see anything about console errors
https://github.com/Expensify/App/issues/52157 based on the comments in the issue it seems no longer reproducable
https://github.com/Expensify/App/issues/52034 there are no console errors, its just issue for implementing tests
https://github.com/Expensify/App/issues/51761 I think everything is sorted here, also I dont see any mentions about console errors
https://github.com/Expensify/App/issues/51181 this seems to be sorted out and soon will be closed
https://github.com/Expensify/App/issues/50780 this seems to be a bug in the Onyx, I can tackle it here
https://github.com/Expensify/App/issues/49954 there is already contributor assigned to this bug and console errors are related to this bug so lets leave it for them
https://github.com/Expensify/App/issues/49819 this seems to be already fixed on the lib side, so we need to wait till its released and then upgrade package in our repo
https://github.com/Expensify/App/issues/47708 this seems to be a backend issue and no console errors
https://github.com/Expensify/App/issues/47078 there is already a contributor assigned and console error is caused that we are not supporting specific file extensions
https://github.com/Expensify/App/issues/46615 this seems to be already handled in other issue
https://github.com/Expensify/App/issues/40041 this seems to be on hold becasue of some internal initiative which is not a priority now

gulp, about to hop offline, will make a note to review tomorrow.   Thx @kubabutkiewicz !

Shared a proposal for fixing warnings about cycle dependecies on open-source channel

Thanks for posting in #expensify-open-source @kubabutkiewicz , it looks like there's broad support to move forward with your plan.  Would it be helpful to reorganize the list of links you posted above to denote which will be addressed with your plan?  For dupes, can you comment on the one you'd recommend closing?  (if not, I can get to next week, got a few other priorities before the weekend).  Thx again, happy to be making progress here.

I will do it today @mallenexpensify !

@mallenexpensify So from the list above in that issue I would tackle those

https://github.com/Expensify/App/issues/52969
https://github.com/Expensify/App/issues/50780
https://github.com/Expensify/App/issues/49819

Beside those from a list

Go forward with a fix for cyclic dependencies which part of is the proposal on open source channel and this will be my main focus for now
No native ExponentConstants module found, are you sure the expo-constants's module is linked properly? warning
I would also dig into the app and look for more console errors because I know that there are more 😅

Thanks @kubabutkiewicz , OP updated

In the meantime I will look at https://github.com/Expensify/App/issues/50780 but for now I am not able to reproduce that.

Thx for the updates @kubabutkiewicz

ask someone from infrastructure team or something like that, because the problem is that we have set up CSP

Can you post in #expensify-callstack to see if anyone in that room might be able to help or provide feedback? If that doesn't work I can cross-post from there to an engineering chat room to get 👀

@mallenexpensify Today in the morning I checked staging and prod envs and the error from https://github.com/Expensify/App/issues/52969 is not appearing today. I will check it tomorrow if it still be not reproducable I think we can close it.

Also https://github.com/Expensify/App/issues/50780 is not reproducible anymore

@mallenexpensify Took a look at https://github.com/Expensify/App/issues/49819 and we have to wait for an upgrade of package pdfjs-dist in react-pdf where there is already a PR to do it its just waiting for a maintainer to review. I think we should wait till it will happen rather than patching in on our own. Wdyt? When it will happen we will need to just upgrade react-pdf in our package react-fast-pdf and then in Expensify repo
also about https://github.com/Expensify/App/issues/52969 today I was able to reproduce that, I will post a question on a channel if there is someone who can adjust CSP on the web server.
After that I will dig into app to look for other console errors

Daily update:

Waiting for a maintainer of react-pdf to check PR then we will be able to proceed further with https://github.com/Expensify/App/issues/49819
I took care my PR  where there was a lot of eslint error after recent changes about defaulting IDs
Dig a bit more about issue https://github.com/Expensify/App/issues/52969 and left a message in our convo on slack

Daily update:

I resolve comments and CI problems on my PR  regarding cycle dependecies
I have created a draft PR with new eslint rules to enforce new style of imports to prevent creating new cycle dependecies
PR for fixing this issue https://github.com/Expensify/App/issues/49819 was merged on the third party lib side I am working right now on upgrading it on our side, will prepare PR tomorrow after finishing testing
About that issue https://github.com/Expensify/App/issues/52969 I left a message on slack convo if we can find someone on the server side who can take a look if there is a CSP configured

@mallenexpensify I will be OOO from 23.12 - 1.01 should we find someone to take over from me for that time or is it fine to leave it for me when I come back?

I will be OOO from 23.12 - 1.01 should we find someone to take over from me for that time or is it fine to leave it for me when I come back?

@kubabutkiewicz , it's fine to wait til you're back, enjoy your break!


HGNC import

Reorganised HGNC imports to treat genes as subclasses of SO:gene.
fixes #2231

@cmungall check the sparql query only to get the picture


Allow for double equal signs to ==highlight text== in Markdown

Allow for double equal signs to ==highlight text== in editor and preview views.
CommonMark standard doesn't include support for highlight, but some popular markdown editors are using double equal signs to show highlighting: Typora, Obsidian, Quilt, Joplin and iA Writer.
==highlight==

Roam also supports highlighting, but uses double carets instead of equals: ^^highlight^^.

Our built-in markdown support targets CommonMark
Highlighting with == looks like an extension to markdown so it's not something we would ship built-in. However support for this can be added by a vscode markdown extension: https://code.visualstudio.com/api/extension-guides/markdown-extension


Add polyring.club

This PR is:

[x] Adding a new domain
[ ] Updating existing domain size
[ ] Changing domain name
[ ] Removing existing domain from list
[ ] Website code changes (512kb.club site)
[ ] Other not listed

[x] I used the uncompressed size of the site
[x] I have included a link to the Cloudflare report
[x] This site is not an ultra minimal site
[x] The following information is filled identical to the data file

I confirm that I have read the FAQ section, particularly the two red items around minimal pages and inappropriate content and I attest that this site is neither of these things.

[x] Check to confirm

- domain: polyring.club
  url: https://polyring.club/
  size: 9.94
  last_checked: 2024-12-13

Cloudflare Report:  https://radar.cloudflare.com/scan/3415f76d-d84a-4cb5-83c4-653ab71892ce/summary

This is too minimal im afraid.


Partial re-drawing in frame

Hi there,
Is it possible to only redraw a sub-rectangle of the entire frame? I am currently trying to do that by using nvgScissor, but the region outside my clipped area gets re-drawn as black pixels, instead of having the previous frame contents kept. What am I missing here?
Thank you!
(I know this is not an issue with nanovg, I did not know where else to ask.)

Try FBO.


webhook_decorator: Support notifying bot owner on invalid JSON.

@timabbott: FYI :)

This is probably a good list of candidates to also receive this treatment:
(zulip-py3-venv) tabbott@zaset:~/zulip$ git grep -i json zerver/webhooks/ | grep doc.md
zerver/webhooks/freshdesk/doc.md:   **Encoding** to **JSON** and select the **Advanced** option. Copy and paste
zerver/webhooks/freshdesk/doc.md:   the following JSON into the **Content** box:
zerver/webhooks/freshdesk/doc.md:   **Encoding** to **JSON** and select the **Advanced** option. Copy and paste
zerver/webhooks/freshdesk/doc.md:   the following JSON into the **Content** box:
zerver/webhooks/github/doc.md:   to `application/json`. Select the events you would like to receive
zerver/webhooks/gogs/doc.md:   to `application/json`. Select the events you would like to receive
zerver/webhooks/helloworld/doc.md:> --fixture=zerver/tests/fixtures/helloworld/hello.json \
zerver/webhooks/helloworld/doc.md:curl -X POST -H "Content-Type: application/json" -d '{ "featured_title":"Marilyn Monroe", "featured_url":"https://en.wikipedia.org/wiki/Marilyn_Monroe" }' http://localhost:9991/api/v1/external/helloworld\?api_key\=<api_key>
zerver/webhooks/ifttt/doc.md:   and set **Content Type** to `application/json`. Set **Body** to a
zerver/webhooks/ifttt/doc.md:   JSON object with two parameters: `content` and `topic`, like so:
zerver/webhooks/intercom/doc.md:8. In the **URL** field, enter the URL constructed above. Select `JSON`
zerver/webhooks/mention/doc.md:   above, and set **Payload Type** to **JSON**. After **Test this Step**,
zerver/webhooks/reviewboard/doc.md:   to **JSON**, and click **Create WebHook**.
zerver/webhooks/teamcity/doc.md:   **Legacy Webhook (JSON)**. Uncheck all **Trigger on Events** options,
zerver/webhooks/zabbix/doc.md:        # Build our JSON payload and send it as a POST request to the Zulip incoming web-hook URL
zerver/webhooks/zapier/doc.md:1. Set **URL** to the URL constructed above. Set **Payload Type** to `Json`.

Merged as the two commits ending in ab7d0de78281d03034940267b0e72e91c9faf249, thanks @eeshangarg!  Can you do a follow-up for whatever subset of the above need the same treatment?


Support DATETIME literals

BigQuery can parse DATETIME.
https://cloud.google.com/bigquery/docs/reference/standard-sql/lexical#datetime_literals
Before this PR, SELECT DATETIME '1999-01-01 01:23:34.45' was parsed as DATETIME column with '1999-01-..' alias.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

10 of 10 (100.0%)  changed or added relevant lines in 3 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.01%) to 89.669%

Files with Coverage Reduction
New Missed Lines
%

src/parser.rs
1
83.04%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
8558

Relevant Lines:
9544

💛  - Coveralls

Also, DATETIME was treated as a Custom type in SELECT CAST('1999-01-01 01:23:34.45' AS DATETIME) for example.
ref. https://github.com/sqlparser-rs/sqlparser-rs/issues/503


hermes init doesn't respect $HERMES_STORE

OS: Ubuntu 20.04
janet: 1.10.0-eb9f74a
hermes: v0.0.2-51-geda5c6f
steveno@shawnee:~$ echo $HERMES_STORE
/home/steveno/.hermes/hermes-store
steveno@shawnee:~$ hermes init
error: Permission denied: /etc/hermes
  in os/mkdir
  in ensure-dir-exists [src/pkgstore.janet] on line 88, column 7
  in <anonymous> [src/pkgstore.janet] on line 95, column 5
  in init-store [src/pkgstore.janet] (tailcall) on line 90, column 3
  in <anonymous> [src/hermes-pkgstore-main.janet] on line 287, column 18
  in main [src/hermes-pkgstore-main.janet] on line 285, column 3

Did you export the HERMES_STORE variable?

Did you export the HERMES_STORE variable?

Yes. Otherwise the echo wouldn't work.

no, you could've done HERMES_STORE=... and it would echo, but not be in env.

I guess I didn't then. It appears to work now. Sorry for the churn.


Add listener name to webhooks request

It would be nice if the listener name is included in the webooks request json body.
My goal is to use different authentication logic for different listeners.
For example, I have two listener, hubs and users:
listener.tcp.hubs =  <IP_ADDRESS>:1885
listener.tcp.users =  <IP_ADDRESS>:1887

The json body will have a field, like :
"listener":"hubs"
Then I can use this field to apply corresponding logic.

@dergraf , thanks for your suggestion. But, after I added the "modifiers" object, the auth hook fails.
console log:
2017-12-18 11:03:59.679 [warning] <0.583.0>@vmq_mqtt_fsm:check_user:544 can't authenticate client {"users",<<"NetMQTTpm11379">>} due to error

It seems webhooks do not support "mountpoint" in the "modifiers" object.

Hi @michaelfung you have to override the client_id (just return the same as the client_id you received) when overriding the mountpoint. I'll make a note to document this - seems we forgot about that.

Thanks! That solved my problem.


Build ubuntu [Bug]

🐛 Bug Report
The ./build_ubuntu.sh script produces the following error.

Steps to Reproduce
Following the instructions in the README file.
Expected Behavior
I expected that the compilation succeeds before running cargo install --path .
Your Environment
Rust Version : rustc 1.75.0 (82e1608df 2023-12-21)
Computer OS : Ubuntu 22.04

i have the same issue any fixes?

reproduced. Looking into this.

duplicate of #3023, closing this one.


Add hooks to be triggered before and after code generation

FYI: https://the-guild.dev/graphql/codegen/docs/config-reference/lifecycle-hooks

Thank you! For now, some of usecases (like running prettier against generated files) might be workarounded by using the new --output-format json CLI option and some shell script magic.


sdk/state: support non-native asset

The channel state machine supports a single native asset balance but should a non-native asset. The txbuild functions may also need expanding to support this change. The tests should be updated to use a non-native asset as well.

was completed with this PR: https://github.com/stellar/experimental-payment-channels/pull/87


x/build: have gopherbot ping a CL when it has +2 but OP can't submit

Have gopherbot ping a CL when it has +2 but OP can't submit.

Temporary workaround: (search only works for people with sufficient Gerritt access)
https://go-review.googlesource.com/#/q/status:open+label:Code-Review%253D%252B2+(-ownerin:"approvers"+AND+-ownerin:"admins")
Gopherbot work is underway in http://golang.org/cl/38385
/cc @aclements @kevinburke

GitHub seems to munge that URL. Let's try this:
https://go-review.googlesource.com/q/status:open+label:Code-Review%253D%252B2+(-ownerin:%2522approvers%2522+AND+-ownerin:%2522admins%2522)

@andybons, I was just discussing this bug with @robpike. Even if we fix this, it doesn't help Upspin or Perkeep, etc. This seems like something that Gerrit should just surface in the UI, to highlight when something is +2'ed (or otherwise submittable) but the Author doesn't have permission themselves to press Submit.
Could you file a Gerrit bug using the correct Gerrit terminology?

https://bugs.chromium.org/p/gerrit/issues/detail?id=9247

Gerrit changed and we can no longer do that query.
More motivation to fix this bug and do it ourselves.
/cc @dmitshur @bcmills

I submited ACL change https://go-review.googlesource.com/c/All-Projects/+/178682 to let gopherbot have access to this info.

... well, that didn't work. The only way I can get gopherbot to have access to query a group's members is to make gobot be an admin, which I'd rather not do.
@andybons, do you know which permissions/capabilities our gobot user needs to have in order to use https://godoc.org/golang.org/x/build/gerrit#Client.GetGroupMembers ?


K8SSAND-1149 ⁃ Do not use client.DeleteAllOf to delete ServiceMonitors

If we know or can compute the key for an object it is best to delete by key. ServiceMonitors however are deleted by calling client.DeleteAllOf.
#260 provided the initial ServiceMonitor integration for CassandraDatacenter and Stargate objects. The reconciliation logic handles deletions as follows:
func (cfg PrometheusResourcer) CleanupResources(ctx context.Context, client runtimeclient.Client) error {
	if len(cfg.CommonLabels) < 1 {
		return errors.New("no labels were found to target deletion request")
	}
	if err := cfg.validate(); err != nil {
		return TelemetryConfigIncomplete{}
	}
	var deleteTargets promapi.ServiceMonitor
	err := client.DeleteAllOf(ctx,
		&deleteTargets,
		runtimeclient.InNamespace(cfg.MonitoringTargetNS),
		runtimeclient.MatchingLabels(cfg.CommonLabels),
	)
	if err != nil {
		return err
	}
	return nil
}

We had some back and forth discussion about the usage of DeleteAllOf while #260 was in flight. In fact, I initially suggested using it and then later suggested switching to client.Delete(). If the ServiceMonitor CRD is installed the k8s cluster, then CleanupResources could in fact be called frequently.
After thinking about it some more, we should be using client.Delete() and not client.DeleteAllOf.
While this code isn't necessarily executed all the time, there are performance considerations that merit the change.  With DeleteAllOf I believe the api server has to fetch all ServiceMonitors in the namespace. It then does the label filtering on the client side (with respect to etcd).  Let's contrast this with doing a get followed by a delete.
There are a couple alternatives to using DeleteAllOf. We could simply do a client.Delete() to delete by key. This is slightly better but we still hit the api server every time CleanupResources is called. Let's consider first doing a client.Get(). If the ServiceMonitor doesn't exist or has already been deleted, Get() will return a not found error in which case there is not need to call client.Delete(). This is good because all reads go against the cache which means we would eliminate a lot of unnecessary calls against the api server. But what if the cache is stale? Not a problem. It can be and often is. If/when that happens it will get sorted out on a later reconciliation.
This should be done for 1.0.0.
┆Issue is synchronized with this Jira Task by Unito
┆fixVersions: k8ssandra-operator-v1.0.0-beta.1
┆friendlyId: K8SSAND-1149
┆priority: Medium

The formatting on my comment above is pretty horrendous, recommend reading it here.

The typed client does hit the api server on every call to DeleteAllOf. Here is the full method impl:
func (c *typedClient) DeleteAllOf(ctx context.Context, obj Object, opts ...DeleteAllOfOption) error {
	o, err := c.cache.getObjMeta(obj)
	if err != nil {
		return err
	}

	deleteAllOfOpts := DeleteAllOfOptions{}
	deleteAllOfOpts.ApplyOptions(opts)

	return o.Delete().
		NamespaceIfScoped(deleteAllOfOpts.ListOptions.Namespace, o.isNamespaced()).
		Resource(o.resource()).
		VersionedParams(deleteAllOfOpts.AsListOptions(), c.paramCodec).
		Body(deleteAllOfOpts.AsDeleteOptions()).
		Do(ctx).
		Error()
}

The c.cache.getObjMeta(obj) call is simply to get the type information so that it can convert from the group/version/kind (GVK) to the group/version/resource (GVR). What follows is the delete call against the api server.
CleanupResources() can be called frequently in some situations. Suppose the K8ssandraCluster deploys both Stargate and Reaper.  After reconcileCassandraDCTelemetry() is called, reconcileStargate() is called. The controller requeues until Stargate is ready. On each requeue, CleanupResources() is called again.
Then after Stargate is ready, reconcileReaper() is called. Similar to Stargate the controller requeues until Reaper is ready. So on each subsequent requeue CleanupResources() is called again.
You might be skeptical, but I am not skeptical about the cost/performance of avoiding extra requests against the api server 😉 .
I agree that first doing a Get is more verbose. The benefit of avoiding calls against the api server make it worthwhile though. This is the approach we take everywhere else.

The c.cache.getObjMeta(obj) call is simply to get the type information so that it can convert from the group/version/kind (GVK) to the group/version/resource (GVR).

Fair enough, I've dug a bit deeper and I can see you're right on this. I should have looked more closely at how the o.Delete() call worked before.


README Unclear

Is this a viable alternative to CoinHive on a site, or is this just so I can mine from a browser using their Javascript Miner?

Hello, this script does the same service as coinhive.com, but mine directly to your pool, you need to run this script in you server to your visitors connect. So you do not pay 30% to coinhive, that's just great.

Sweet. Would it work using github pages?

No, this site only shares the source code, you must have a server to run this script.

I meant I am hosting on Github Pages, so if I add this code to my site's repo will it work? Or do I need to host it on a separate server for it to be accessed?

you need a server with a python environment

So if I had a server with python, I could connect the user miners from my site through the proxy to an actual exchange?

@Emiller88 yes, the proxy will connect the web of miners and the pool

Sounds good. We're having an issue with setting up web sockets properly because they're not secure. Any advice? Feel free to shoot me an email also

@Emiller88  see https://github.com/x25/coinhive-stratum-mining-proxy/issues/4


The "completed_tasks" command does not work

Hi,
thanks for the awesome software, very clean code :+1:
I noticed this line in your code:
def completed_tasks(db_path, auth):
    ...
    if num_items == 0 or True:  # this evaluates always to True, the completed items are not being downloaded
        break

To me it looks like some kind of temporary debugging change which got committed by accident ...

Whoops! Thanks for the report. This should be fixed with v0.2 https://github.com/bcongdon/todoist-to-sqlite/releases/tag/v0.2


Added Dart Programming Book

Title: Dart Apprentice (First Edition) Beginning Programming with Dart
What does this PR do?
Add resource(s)
For resources
https://dokumen.pub/download/dart-apprentice-1nbsped-1950325326-9781950325320.html
Description
There are many programming languages you can start learning today. But not many are as modern, easy to learn, object-oriented, and scalable as Dart. Plus, combined with Flutter, Dart allows you to build native iOS, Android, web, and desktop applications with a single code base.

Hope you accept my PR with the Hacktoberfest-accepted tag

In general, we do not link to file sharing sites, or file hosting sites such as google docs. or dropbox.
This appears not to be an authorized distribution. Please see CONTRIBUTING.md guidelines.


fixed #1998 - [closed]

In GitLab by @liyanq528 on Mar 27, 2019, 08:47
Merges issue#1998 -> dev

In GitLab by @wknet123 on Nov 13, 2019, 11:41
The test coverage for backend is %  38.85%  , check  console log

In GitLab by @wknet123 on Nov 13, 2019, 11:41
closed


Need to compile Sass with catalog start

I'm looking at integrating Catalog for the documentation end of a design system I'm building. It's Sass files for CSS and React components packaging the HTML. I have the React components working in the page right now (Awesome!), but I'm not sure how to get the CSS to build and included (hopefully globally).
I've included the file main Sass file into the Catalog component but it's not actually compiling anything. It's expecting a CSS file.
Any advice?

@mattfelten, AFAIK it should be as straight-forward as requiring your .scss file with all its imports in styleguide.jsx:
import React from 'react';
import ReactDOM from 'react-dom';
import { configureRoutes } from 'catalog';

import Styles from "my-styles.scss";

const routes = configureRoutes({
  title: 'My Styleguide',
  basePath: '/',
  pages: [
    { component: require('./docs/intro'), path: '/', title: 'Introduction' },
  ]
});

You can also contextualise your SASS files and require them directly from component React js or jsx file:
import React from 'react';

require('./PrimaryButton.scss');

const PrimaryButton = props => <button className={`my-button`}>{props.children}</button>;

There are two ways:

You can pre-build your SASS code and include the bilt CSS, see https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#adding-a-css-preprocessor-sass-less-etc
You can use a catalog.config.js file to add sass-loader, see https://docs.catalog.style/guides/webpack-babel

Let me know if that works.

I got the pre-built Sass version to work so I'm going with that for now. Thanks!
So I like the second option better because it seems cleaner, but I couldn't figure out how to get it to work. If you have time, here's the 3 different ways I tried: https://gist.github.com/mattfelten/854685ef6cca02b177901176398e38dd I don't know enough about webpack I don't think.

I think you need to prepend the sass-loader to module.rules but I haven't tested it. Otherwise your first option looks like the best one (the other two definitely don't work).

I realize this issue is a bit old, and I am happy starting a new issue if you prefer it @herrstucki, but I wanted to check if it's possible to get a snippet of a catalog.config.js file with a working sass-loader setup.
I've tried a few different ways to merge my webpack config in, using a working /.scss$/ loader rule from another project, but always run into various errors.
Also, is it possible to import sass only for certain specimens, to avoid affecting the layout of the overall Catalog?
Let me know if there's a better place to ask these questions, and I'll do that. 😅
Thanks!

@nickjohnson-dev Doesn't the CRA guide work for you (i.e. prebuilding SCSS and then importing the CSS in Catalog)?
Off the top of my head, something like this may work:
// catalog.config.js
module.exports = {
  webpack: (webpackConfig) => {
    webpackConfig.module.rules = [
      {test: /\.scss$/, use: 'sass-loader', options: {}},
      ...webpackConfig.module.rules
    ])
    return webpackConfig;
  }
}

@herrstucki I'm not rigidly opposed to just compiling my SCSS code and then importing it, but it seemed like you had gone to the trouble to support custom webpack loaders, and I didn't see an obvious reason why this wasn't working.
Using the code you provided, with the loaders necessary to load in the styles:
module.exports = {
  webpack: config => {
    config.module.rules = [
      {
        test: /\.scss$/,
        use: 'style-loader!css-loader!sass-loader',
      },
      ...config.module.rules,
    ];
    return config;
  },
};

...I am getting this error:
This relative module was not found:

* ./styles.scss in ./catalog/index.js

I'm using the same versions of all the relevant dependencies that I use in other projects, and I'm unsure what the difference here would be.

It seems like your styles.scss is not in the correct place? The error message it should be at catalog/styles.scss …

Yeah, I did make sure that the files were in the right place and everything, and I was still getting the error no matter what I changed with the location of the file.
Fortunately, for my use case I think that I've gotten a good workflow down with just compiling the SCSS files in my npm "prestart" script and then loading them as css, so I'm not blocked by this issue.
I appreciate you taking a look at it though!

Having the same issue when trying to add a new module rule to handle the scss - no matter where I place the sccs file I get "This relative module was not found".
I've opted to use a postinstall script to compile the scss - but Ideally I'd like to get it all working from the webpack config - I'm not sure whats effecting the path.

I also ended up using quite a bit of time trying to load .scss files directly, but it seems there are currently some performance and other issues with Webpack plugins for Sass. I ended up following the CRA instructions to the letter and got a solution I'm quite happy with:
// package.json
{
  "name": "catalog",
  "dependencies": {
    "catalog": "^3.0.0-rc.4",
    "node-sass-chokidar": "^1.1.0",
    "npm": "^5.7.1",
    "npm-run-all": "^4.1.2",
    "react": "^16.2.0",
    "react-dom": "^16.2.0"
  },
  "scripts": {
    "build-css":
      "node-sass-chokidar --include-path ./catalog --include-path ./node_modules catalog/ -o catalog/",
    "watch-css":
      "npm run build-css && node-sass-chokidar --include-path ./catalog --include-path ./node_modules catalog/ -o catalog/ --watch --recursive",
    "catalog-start-js": "catalog start",
    "catalog-build-js": "catalog build",
    "catalog-start": "npm-run-all -p watch-css catalog-start-js",
    "catalog-build": "npm-run-all build-css catalog-build-js",
    "start": "npm run catalog-start",
    "build": "npm run catalog-build"
  }
}

Then I can place an index.scss in e.g. components/core/index.scss and load it from index.js as:
import React from "react";
import ReactDOM from "react-dom";
import { Catalog, pageLoader } from "catalog";
import "./components/core/index.css";

const pages = [
  {
    path: "/",
    title: "Introduction",
    content: pageLoader(() => import("./WELCOME.md"))
  }
];

ReactDOM.render(
  <Catalog title="MyCatalog" pages={pages} />,
  document.getElementById("catalog")
);

I also ignore .css files in .gitignore:
catalog/**/*.css

Also worth noting – for some reason whatever method of trying to import the styles as per the Catalog docs, it doesn't work. That's why I ended up just importing the css using ES6 modules. For example this didn't load the style:
const pages = [
  {
    styles: ["./components/core/index.css"],
    path: "/",
    title: "Introduction",
    content: pageLoader(() => import("./WELCOME.md"))
  }

OK, my config got a bit more complicated because I started using lerna for managing multiple npm packages inside a single repo. Ended up overriding my catalog.config.js to get Sass loading to work from the root of the project:
const path = require("path");

const modulesPath = path.resolve(__dirname);

module.exports = {
  webpack: config => {
    config.module.rules.push({
      test: /\.scss$/,
      loaders: [
        "style-loader",
        "css-loader",
        {
          loader: "sass-loader",
          options: {
            includePaths: [modulesPath]
          }
        }
      ],
      include: modulesPath
    });
    return config;
  }
};

More info on the setup here.


support laravel 8

Summary of the change:
Hi Owner,
I am not so sure if this is the correct way to pull request for the adjustment i done. i desperately need this cool package to be able to support laravel 8 so i did little changes to illuminate/support.
to be very honest, i had tried
|| 8.*

but it seem still doesn't work. so i changed to ~8 and it works on my side.
pls verify. thanks

Laravel 8 support has already been added, see: https://github.com/UniSharp/laravel-filemanager/commit/c20d71a624aab6aa8162353aff0155c14e56fefd
However no new tag has been pushed yet allowing you to include it.
If you require the master branch it is able to install on L8, however I do not know if this is a stable version
composer require unisharp/laravel-filemanager dev-master

I had tried. But it can't work. I'm not sure why.

Fixed in v2.2.0, thanks for reporting this.