Mac air M1 - double parenthesis

Good morning,
I am using m1 Mac and run across a possible issue with Pipenv recently (like here https://stackoverflow.com/questions/70246087/pipenv-found-itself-venv-is-displayed-with-double-brackets)
I installed Pipenv:
python -m pip install pipenv
Pipenv shell creates an environment but I get two parentheses each time a program is run. Regardless if using IDE or in Terminal.
✔ Successfully created virtual environment!
Virtualenv location: /Users/xxx.local/share/virtualenvs/pipenv-opVGfhGc
Creating a Pipfile for this project...
Launching subshell in virtual environment...
. /Users/xxx/.local/share/virtualenvs/pipenv-opVGfhGc/bin/activate
xxx@Filips-MacBook-Air pipenv %  . /Users/xxx/.local/share/virtualenvs/pipenv-opVGfhGc/bin/activate
does anyone have an idea how to fix this ?
$ pipenv --support
$ pipenv --support
Pipenv version: '2021.11.23'
Pipenv location: '/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/pipenv'
Python location: '/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9'
Python installations found:

3.10.1: /usr/local/bin/python3
3.9.7: /Library/Frameworks/Python.framework/Versions/3.9/bin/python3
3.9.7: /Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9
3.9.7: /usr/local/bin/python3.9
3.8.9: /usr/bin/python3
2.7.18: /usr/bin/python
2.7.18: /usr/bin/python2
2.7.18: /usr/bin/python2.7

PEP 508 Information:
{'implementation_name': 'cpython',
 'implementation_version': '3.9.7',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '21.2.0',
 'platform_system': 'Darwin',
 'platform_version': 'Darwin Kernel Version 21.2.0: Sun Nov 28 20:29:10 PST '
                     '2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T8101',
 'python_full_version': '3.9.7',
 'python_version': '3.9',
 'sys_platform': 'darwin'}

System environment variables:

TMPDIR
__CFBundleIdentifier
XPC_FLAGS
TERM
SSH_AUTH_SOCK
XPC_SERVICE_NAME
TERM_PROGRAM
TERM_PROGRAM_VERSION
TERM_SESSION_ID
SHELL
HOME
LOGNAME
USER
PATH
SHLVL
PWD
OLDPWD
__CF_USER_TEXT_ENCODING
PIP_DISABLE_PIP_VERSION_CHECK
PYTHONDONTWRITEBYTECODE
PIP_PYTHON_PATH
PYTHONFINDER_IGNORE_UNSUPPORTED
PIPENV_ACTIVE
PS1
LC_CTYPE
_
PIP_SHIMS_BASE_MODULE

Pipenv–specific environment variables:

PIPENV_ACTIVE: 1

Debug–specific environment variables:

PATH: /Users/fafa95/opt/anaconda3/bin:/Users/fafa95/opt/anaconda3/bin:/Library/Frameworks/Python.framework/Versions/3.9/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
SHELL: /bin/zsh
PWD: /Users/fafa95

Closing this for now as I think this was fixed in 2021.1.8 that was released yesterday, see the changelog has:

Remove the extra parentheses around the venv prompt. #4877

Also I see the stackoverflow you link to has a recent new comment from someone regarding something to do with pipx.   Let us know if you think this is still an issue or open question in the latest  pipenv==2021.1.8 release.  Thanks!


The redirect URI included is not valid.

Hi,
I have clone, migrate database, and configure GitLab.
I'm trying to sing-in to the app. This my callback url which I pass in GItLab "http://laravel-gitscrum.dev/auth/provider/gitlab/callback".
I got the error message "The redirect URI included is not valid.".
Anyone experience this?
Thanks,
Punleu

Hi,
I had the same problem. I don't know why but the URI does not pass the validate_redirect_uri method tests of DoorKeeper::OAuth::PreAuthorization class in GitLab. A workaround is force the method to return "true". Go to DoorKeeper gem directory and edit the file "lib/doorkeeper/oauth/pre_authorization.rb":
      # TODO: test uri should be matched against the client's one
      def validate_redirect_uri
        return false unless redirect_uri.present?
	  Helpers::URIChecker.valid?(redirect_uri)
#        return false unless redirect_uri.present?
#        Helpers::URIChecker.native_uri?(redirect_uri) ||
#          Helpers::URIChecker.valid_for_authorization?(redirect_uri, client.redirect_uri)
      end

Restart GitLab.

Hi,
I know it's long since and you might have already found a solution.
I recreated this error and it is caused by the APP_URL variable in the  .env file being different from the URL used in the callback gitlab callback URL.
Make sure as described in the documentation that : - http://{URL is the SAME APP_URL}/auth/provider/gitlab/callback


The "GenerateScript" task failed unexpectedly

While building a project I got the following error
System.NullReferenceException: Object reference not set to an instance of an object.
   at Bridge.Contract.EmitterException.get_FileName()
   at Bridge.Build.GenerateScript.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__20.MoveNext()```

Thank you for the report! Could you, please, provide a test case?

Hi Daniil,
I've tried to convert C# solution big enough. To make it as the test case I
need to shrink it.Currently, I'am busy, will try to do that in a couple of
days.
Yuri
On Tue, Dec 15, 2015 at 4:19 AM, Daniil Veriga<EMAIL_ADDRESS>wrote:

Thank you for the report! Could you, please, provide a test case?
—
Reply to this email directly or view it on GitHub
https://github.com/bridgedotnet/Bridge/issues/745#issuecomment-164696380
.

Thank you! It would be a great help.

I've refactored my C# code and the issue has gone.
On Tue, Dec 15, 2015 at 4:54 PM, Daniil Veriga<EMAIL_ADDRESS>wrote:

Thank you! It would be a great help.
—
Reply to this email directly or view it on GitHub
https://github.com/bridgedotnet/Bridge/issues/745#issuecomment-164908145
.

Thank you for the update.
Okay, I am labeling the issue as question and closing. If the same issue appears again, please feel free to comment here and we'll re-open the issue.


Pixmap Slicer

Summary
Integrated the Pixmap Slicer plugin into the EditorBase Duality project as discussed in #650. I am submitting this PR to get feedback on the current state - I am sure there are quite a few changes to make before it is ready to merge.
Features

Auto-Slicing of a Pixmap with configurable alpha cutoff
Add/delete/modify rects
Zoom/Pan the Pixmap during slicing
Rects can be ordered by clicking on them in the desired order

You can access the slicing window by right-clicking any Pixmap resource and selecting "Slice Pixmap". To modify a rect, click on it and then drag its edges around.
Known Issues

Closing the editor with a slicing form active and re-opening it will leave you with a useless slicing form. Selecting "Slice Pixmap" should always use an existing slicing form if possible.
Lack of IHelpProvider implementation for advisor view
Tooltips need to be improved
Dragging the bottom/right past the top/left of a rectangle doesn't work right
Colors/Look-and-Feel of slicing form don't quite match the rest of Duality

Screenshots
Default View (image not included):

After Auto-Slicing:

Adding a New Rect:

Defining Rect Order:

Progress

Added Undo/Redo support
Added IHelpProvider implementations
Fixed negative width/height bug

ToDo

Tooltips
Reuse existing Pixmap slicing form when possible
Make sure look-and-feel matches other Duality windows as close as possible
Form/EditorAction Icons
Make sure all string are in resources where possible
Extract pixmap slicing algorithm somewhere reusable

Progress

Pixmap slicing algorithm extracted from the form subfolder
Tooltips for non-obvious buttons
Icon for the window and editor action popup
Moved many displayed strings into resources. Not finished here.
Pixmap slicer forms are now re-used

ToDo

Finish moving displayed strings to resources
Make sure look-and-feel matches other Duality windows

Good progress and writeup 👍 Give me a few days and I'll look into it to provide feedback.

The "delete all" and "order rects" (the one with the hash) icons I created in GIMP by modifying one of the Silk icons. I'm not quite liking the "order rects" one yet.

The icons look somewhat blurry - are they scaled by the toolstrip somehow?

(You still seem to be working on this - ping me when you'd like to wrap stuff up for a review and merge)

Actually, I'd say it's ready for a review now.

So... I've never really taken a look at Duality's Tileset Editor. After doing so, I've determined some new features I'd like to add to this Pixmap Slicer to match the Tileset Editor in look and feel and to just enhance it's capabilities in general:

Toggle Background
Show Tile Indices

None, hovered, and all, just like Tileset Editor
Also, make styling of Pixmap Slicers indices match that of the Tileset Editor

Buttons for zoom in/out/reset
Apply/Revert

This is more minor as I feel undo/redo support is probably enough for the Pixmap Slicer (which it already has)

I'm going to get to work on those now :)

Done. Mirrors the Tileset Editor quite closely now. I copied over the icons that the Tileset Editor uses into the EditorBase project. I'm not sure if there is somewhere common they should be moved instead. I didn't bother adding the apply/revert stuff - I feel like the edits inside of the Pixmap Slicer are just a lot simpler than those in the Tileset Editor and so Undo/Redo is enough.

[image]

Wow. Really looking forward to this. Nice work 👍

I didn't bother adding the apply/revert stuff - I feel like the edits inside of the Pixmap Slicer are just a lot simpler than those in the Tileset Editor and so Undo/Redo is enough. And, there is no resource compilation needed with Pixmap Slicer.

Agree completely, good call.

Gave it a quick first look, solid piece of work so far 👍 Here's a first list of change / feature / bugfix / polishing requests:

Some namespaces are quite extensive and contain classes that will likely conflict with others due to somewhat generic names - can we use more specialized names and shorter namespaces instead?

Specifically looking at Utilities.cs, Side.cs and PixmapSlicing.cs.
Would prefer if we can avoid having a separate namespace for pixmap slicing.
Maybe rename PixmapSlicing to PixmapSlicingUtility and unify with Utilities, moving both of them into the Duality.Editor.Plugins.Base namespace.
Consider renaming Side to something more specific (like PixmapSlicerRectSide), or make it a private nested class of the slicer form, so it doesn't need its own namespace to exist.

When changing states in the slicer form, the tool buttons visibly disappear and pop into existence. There's probably a spot where SuspendLayout / ResumeLayout, or its equivalent for toolbars needs to be called.
Dragging a rect side feels somewhat slow, and I get an audibly high CPU (fan) load from doing that. Something may be off with performance here. Maybe it's not actually the drag operation, but the redraw of the control, not sure.
Zooming in on a previously centered sprite sheet will spawn scroll bars, even if it would still fit comfortably into the view area.
Hitting the "Show Indices Display Mode" button after zooming in and out will re-center the image, showing that it was off center before.
The dark background mode needs other colors for the slice rects in regular / selected state, as they are hard to read "dark on dark".
When a rect is selected, you can hover and drag its edge beyond its corners. To test this, switch to "show index on hover" mode and note how the index is displayed when hovering beyond the corner. Click + drag works there as well.
The sprite sheet extents / border should be visibly displayed, so the user can distinguish between transparent areas and regions outside the sprite sheet.
It's unclear to me as a user what happens when I start specifying the order of atlas rects, but then hit the "Ok" button before I specified all of them. I still get the full number, and their order did change, but I don't know how all others are ordered. Should we disallow this, or maybe switch on rect index display as an FYI?
My "Show Indices Display Mode" is discarded after completing a manual order setup.
The grid slicer should probably have a min setting of one row and one column. Wouldn't know what to use zero for, and it allows to enter an inconsistent state when reducing one setting to zero and back up after specifying the other. Also, it's possible to get a NullReferenceException when attempting to complete grid slicing with zero rows and zero columns.
The image is displayed a bit blurry, even though no zoom is active and it fits entirely into the view - can we get this to work pixel-perfect in those cases, as well as all Nx (2x, 3x, 4x, ...) zoom levels?
I can switch which Pixmap to edit in an already open PixmapSlicer by simply right-clicking the other and invoking the slice action. Can we simplify this and let the slicer window automatically react to editor selection? That way, I'd just need to select the other Pixmap and could begin slicing immediately.
When zooming in, the rects get a bit erratic in their width, which feels buggy. Can we get them to always be one pixel wide regardless of zoom?
Also, I think it would be great if dragging a rect side would snap, so the resulting atlas rect is always defined in full pixels.
It is currently possible to zoom with the mouse wheel, which is really nice. However, the zoom will not respect the current view center, so zooming in will always "move the view" towards the upper left, and vice versa. It would be great if the zoom was always towards the current view center.
It is currently possible to drag the side of a rect until it's below zero size. The rect will disappear and only be accessible in the Object Inspector, or via "Delete All".

I really like the auto-zoom on resize, how the inspector updates in realtime, the full undo / redo support, how it all integrates with the rest of the editor, and of course auto and grid slicing itself. So there's some polishing left to do, but still really nice work overall 👍

Some namespaces are quite extensive and contain classes that will likely conflict with others due to somewhat generic names - can we use more specialized names and shorter namespaces instead?

I improved the Side and Utilities namespaces. I kept the states in their own namespace as there are quite a few classes there and no one else should ever really need to reference them.

When changing states in the slicer form, the tool buttons visibly disappear and pop into existence. There's probably a spot where SuspendLayout / ResumeLayout, or its equivalent for toolbars needs to be called.

Good catch. Fixed.

Dragging a rect side feels somewhat slow, and I get an audibly high CPU (fan) load from doing that. Something may be off with performance here. Maybe it's not actually the drag operation, but the redraw of the control, not sure.

Pretty sure its the redraw resizing causes a lot of invalidation events. I tried at one point to invalidate only the necessary region rather than the whole form and it didn't make much difference. I'll take another look at this.

When a rect is selected, you can hover and drag its edge beyond its corners. To test this, switch to "show index on hover" mode and note how the index is displayed when hovering beyond the corner. Click + drag works there as well.

Can't believe I missed that bug for so long... it was an error in how I was calculating distance to a rect from a given mouse position. Fixed

The sprite sheet extents / border should be visibly displayed, so the user can distinguish between transparent areas and regions outside the sprite sheet.

Only the image background uses the checkboard now. The rest of the display will be a gray color.

It's unclear to me as a user what happens when I start specifying the order of atlas rects, but then hit the "Ok" button before I specified all of them. I still get the full number, and their order did change, but I don't know how all others are ordered. Should we disallow this, or maybe switch on rect index display as an FYI?

I definitely don't think it should be disallowed. The advisor window provides a help message here saying that all other rects will be placed at the end of the atlas. It maybe should say that it is in no particular order. Technically there is some order - it is a stable reordering so the relative order of unclicked rects will be maintained afterwards.

The image is displayed a bit blurry, even though no zoom is active and it fits entirely into the view - can we get this to work pixel-perfect in those cases, as well as all Nx (2x, 3x, 4x, ...) zoom levels?

Hmm, the graphics object is being told to display the image at the highest detail possible so I'm not sure why it would look blurry in that case. When zoomed there is going to be some blur applied of course, but when unzoomed there should not be. I haven't noticed any issue myself but I'll see what I can find out about how images are drawn by Graphics.

I can switch which Pixmap to edit in an already open PixmapSlicer by simply right-clicking the other and invoking the slice action. Can we simplify this and let the slicer window automatically react to editor selection? That way, I'd just need to select the other Pixmap and could begin slicing immediately.

Done.

Also, I think it would be great if dragging a rect side would snap, so the resulting atlas rect is always defined in full pixels.

Done.

It is currently possible to drag the side of a rect until it's below zero size. The rect will disappear and only be accessible in the Object Inspector, or via "Delete All".

Fixed. Can't make rects with zero width of height anymore.

All comments about mouse wheel scroll, zooming, and scroll bars.

I have had a terrible time getting these things to work. I tried to address most of your comments and one point or another and always ran into trouble. As changes to everything else is starting to settle down I will take another look.

I think I have addressed all of your points except for the high CPU load when dragging. In order to make it seem responsive, it needs to invalidate the control with every bit of movement. I tried invalidating only the area that changed and it made no difference while adding quite a bit of mess to the code.
You also said that the resizing feels slow along with the comment about high CPU load. That seems to have been fixed when I made it snap to pixel coordinates.
Regarding the image quality - it is far better now but it still has a very minor blur to it - pretty hard to notice. To achieve this quality, I had to make sure the image preview was generated at the displayed resolution, not at a lower resolution and then scaled up as it was before. I also set the interpolation mode to NearestNeighbor which should be giving the minimum amount of blur. I think the current blur is coming from PreviewProvider as it seems to use linear interpolation when scaling the image.

Wow, you're really fast. Those were quite a few points!

I think the current blur is coming from PreviewProvider as it seems to use linear interpolation when scaling the image.

Honestly I wouldn't use PreviewProvider here at all, as those previews aren't intended for generating the primary view of any editor. They're more of a "give me a quick visual impression" API. If you're doing a specialized editor, prefer a specialized way to draw your view instead.

Note: Anything I didn't respond to above has been fixed, I just simply didn't have anything to add :)

Nice work 👍

I think I have addressed all of your points except for the high CPU load when dragging.
...
Regarding the image quality - it is far better now but it still has a very minor blur to it - pretty hard to notice.

Will get back to you as soon as I manage, and maybe take a look into the performance and blur issue myself to help out where I can.

I can't really remember why I started with using PreviewProvider... well its gone now and so is the blur!
I also did two things to improve resizing performance - resizing only invalidates the updated region and rects are now drawn as a batch. Unfortunately it didn't make a huge difference. I'm seeing about a 10% improvement. After running it through a profiler I can see that the execution time is almost entirely spent within the various Graphics methods. Nothing else really shows up on the profile.

All in all, with this fix and the above performance improvements, dragging is at least 40% faster.

Nice work 👍 Didn't find the time to re-review yet, but hopefully will soon.

Next, I'd like to distinguish between Nx (2x, 3x, ...) ratio zoom levels and other zoom levels:

Handling the fractional and Nx zoom levels differently seems very strange to me. I'd prefer to remove fractional zoom support and just have Nx zoom levels. That would be simpler and still good from a usability perspective - we aren't writing an image editor so we don't need fine grained zoom control if it is going to be an issue.

I'd prefer to remove fractional zoom support and just have Nx zoom levels. That would be simpler and still good from a usability perspective - we aren't writing an image editor so we don't need fine grained zoom control if it is going to be an issue.

I'd be fine with that too. We still need 1/Nx zoom levels though, so it's possible to see the full image and get a quick overview on what the auto-slicing has done, and those need to be properly filtered when scaled down, so we won't dodge that filtering switch entirely.

Worked on this PR a bit more and actually started with a few bigger changes. Still work-in-progress:
When I started addressing the zoom issue, I noticed that all the drawing, scrolling and zooming was handled directly by the docking control, which looked a bit heavy-handed and might fall on our feet later on: Drawing would need to know the layout of the form in order to draw in the right places, scrolling was done manually and invalidation logic would have to be hand-optimized for scrolling scenarios. Also not the typical design you'd expect WinForms wise.
To address this, I gathered all UI-related functionality and created a new PixmapSlicingView WinForms control to house them. This control is intended to work stand-alone, while the form and its states uses the views public API to control it, and add editing functionality on top. This is in line with other places in the editor (such as the Tilemaps editor plugin), and also makes maintaining and re-using UI code a bit easier.
With the new WinForms control, a lot of state-related code could be simplified by simply allowing the editing state to access the view control and its API in order to change settings or transform coordinates. Changing zoom levels no longer re-generates the background image and scrolling re-uses 90% of the previously drawn image and only invalidates the regions that just entered view. It is also handled by WinForms for the most part.
There are, however, a few regressions due to the fact that I haven't had as much time for this as I'd like. I've updated the ToDo list to reflect this and will get back to this as soon as I manage.
ToDo

Regression: The image is no longer centered. Fix this.
Regression: Index labels flicker when dragging rect edges while zoomed in, due to hover state not always matching selection state. Address this by moving selection and edge hovering logic to the PixmapSlicingView and letting the editing state use and configure it.
Regression? Grid slicing now breaks the existing atlas when cancelled.
Zooming in should "snap" to Nx zoom levels.
Re-review latest state and merge back when approved.
Merge from master to v3.0 branch.

If you have any thoughts on this, they're of course appreciated.

I was planning on doing essentially the same refactoring you did here!
To address the regression of the index labels flickering we would just need to force set the hovered rect to the selected rect whenever a selected rect edge is hovered. That's how I had addressed it before and it worked well and was simple.

Regression? Dragging the left or top edge back and forth while zoomed in very far will move the right / bottom edge and shrink the rect.

Sounds like a rounding issue.
I have been short on time myself the last week and probably won't have time over the next few days. When I get the chance I'll take a look and see if I can address any of the ToDo items.

I was planning on doing essentially the same refactoring you did here!

Great to hear 🙂 I managed to put some more work into this. Things start to take shape again.

Sounds like a rounding issue.

That was exactly it. I moved rect clamping and adjustments from view space (which was partially int-locked) into atlas space and the problem no longer appears.

To address the regression of the index labels flickering we would just need to force set the hovered rect to the selected rect whenever a selected rect edge is hovered. That's how I had addressed it before and it worked well and was simple.

I addressed this by moving all of the hover and selection logic into the PixmapSlicingView control, which knows best about that anyway. The editing states now use this information to do their thing, but no longer have to figure out selection and hovering on their own.
With the view now having all of the knowledge in one place again, the fix basically emerged by itself. Very similar, but instead of adjusting the hovering info to match selection, it now displays the indices of selected rects as if they were hovered. That way, you can still get the correct hover info when needed, regardless of selection

Other than the above, there are a few minor API and style changes as usual, and one bigger changes in how Undo / Redo is addressed:
The way I've seen this in the code before, the Pixmap was edited as needed during operations, and then, when finished, committed. This commit involved rolling back to its original state and adding a final UndoRedo action. Makes a lot of sense for dragdrop, as this is one continuous operation you don't want to turn into a stream of UndoRedoActions. However, this has the disadvantage of producing an inconsistent state, where the resource was already edited, but no action was filed yet - and it also requires an explicit "commit" in the end, along with a guarantee to run into it in all cases.
There is a different way to tackle this in Duality, which avoids the downsides of it: Append-able UndoRedoActions. Basic idea is, when filing a new action, it first checks whether it could be appended to the previous registered one. If this is the case, it will be appended / merged into it without producing a new undo stack entry. That way, continuous operations can just append a new action on every step, and the system handles and registers them all as a single action. When done, an optional call to UndoRedoManager.Finish will avoid further merges into the previous action to allow for two distinct dragdrop operations in sequence. Here's my changes to the SetAtlasRect action as an example on how to make an UndoRedoAction append-able.
ToDo

Regression: The image is no longer centered and no longer retains its center-based "viewport position". Fix this.
Regression? Grid slicing now breaks the existing atlas when cancelled.
Zooming in should "snap" to Nx zoom levels.
Re-review latest state and merge back when approved.
Merge from master to v3.0 branch.

I have been short on time myself the last week and probably won't have time over the next few days. When I get the chance I'll take a look and see if I can address any of the ToDo items.

Same here, so no worries, I know how it is. Feel free to pick this issue up again at any point when you have time. I'll do the same and we'll be done when we're done.

@ilexp I've found a few minor bugs that I'm addressing, but I found a different issue that I think warrants discussion.
Originally, you had to select a rect before you could resize it. Now, as long as your mouse is hovering an edge you can start a resize operation by clicking and dragging. When dealing with two rects with overlapping edges this produces a problem as you can have one rect selected and then when trying to click and resize that rect the code determines the other rect is the one you want to use and starts resizing that. I think there are two ways of solving this:

Revert to old behaviour. Only edges of the selected rect can be hovered and thus resized.
Maintain current behaviour where any edge can be hovered, but prefer using the selected rect when multiple edges are hovered.

I'd prefer the first option because it is more consistent from a usability perspective. It is also simpler to implement.
Thoughts?

Short on time, so I'll try to be brief 🙂

Revert to old behaviour. Only edges of the selected rect can be hovered and thus resized.
Maintain current behaviour where any edge can be hovered, but prefer using the selected rect when multiple edges are hovered.

...
Thoughts?

I'd prefer to go with option 2, as requiring to select first is an additional action / click that, from my personal user perspective, feels unnecessary. In most cases, I already select the edge I want to drag in my first click and would expect to be able to immediately move it without an additional interaction first.

Edits: Bugs I had mentioned are fixed.

Nice! 👍

I'd prefer to go with option 2, as requiring to select first is an additional action / click that, from my personal user perspective, feels unnecessary. In most cases, I already select the edge I want to drag in my first click and would expect to be able to immediately move it without an additional interaction first.

Alright I'm fine with that. While looking into this I ran into another issue. When your mouse pointer is within two rects, only the highest indexed one will be hoverable even when the mouse pointer is clearly over a side of the lower indexed rect. This is because hovering over the center of a higher index rect is taking precedence over the side of a lower indexed rect because it break out of the search loop. I'm looking into how to cleanly address this. Ideally, hovered a rect side should always take precedence I think.

Sounds good!
Will get back to the issue as soon as I manage. Let's see if we can start to wrap things up.

Progress

Merged this PR to master.
Triggered a binary release.
Merged master to develop-3.0.


Introduction

How can I describe the source file after putting it in the application?
For example, how would you describe how to implement this simple one?

It is pretty rudimentary content, but please tell me..

@son0417 its not include in source folder, its implement by extension.


TFA project delivery

@constantinus0
I have not yet looked through the code, just fixing some things to make it safe to merge in and make it runnable.
You'll see there are some formatting changers in tfalib.py and tfa_processor.py but they don't affect the running. I'll review the way the imports are set up soon but it looks like they are working. You should use this branch for incoming changes (pull from tfa_dev and push more commits to it, but don't change too much in one commit).
Some notes so far...
I have the docs building at https://swarmpal.readthedocs.io/en/tfa_dev/:
You'll see some of the notebooks run, but a couple are timing out I think - I'll fix that. Though it's a good idea to adjust these demos where possible to make them quicker (the upcoming model performance improvement will help). I'll tidy up how the API page appears... though we'll also need to look at the docstrings to fix that.
To do:

[ ] Things surfaced by the pre-commit checks: src/swarmpal/toolboxes/tfa/tfa_processor.py:79:13: T201 print found.
 src/swarmpal/toolboxes/tfa/tfa_processor.py:96:13: T201 print found.
 src/swarmpal/toolboxes/tfa/tfa_processor.py:115:13: T201 print found.
 src/swarmpal/toolboxes/tfa/tfa_processor.py:544:13: E741 ambiguous variable name 'I'
 src/swarmpal/toolboxes/tfa/tfa_processor.py:547:13: T201 print found.
 src/swarmpal/toolboxes/tfa/tfa_processor.py:592:17: T201 print found.
 src/swarmpal/toolboxes/tfa/tfa_processor.py:611:13: T201 print found.

[ ] Can we review the "I" and "W" variables naming
[ ] Replace prints with logging (I can do this)

[ ] Fix notebooks:

[ ] re-title
[ ] incorrect cluster data supplied (we might skip this demo? / change it to pull the data on-demand - I don't really want to include data files in the repo)
[ ] tidy up

[ ] Add some basic tests. This is mitigated by running the notebooks in the docs build, but I'll come up with something extra to run in the tests. This doesn't need to happen right now

@constantinus0 I've just tweaked the documentation build so now you'll see it working at https://swarmpal.readthedocs.io/en/tfa_dev/toolboxes/tfa/using_tfa_1.html (just do a git pull to synchronise those changes before making more)


update dependencies

Most of them are minor updates, except typescript.

The test failed in this PR, but passed when I pushed to my branch.

Our threading tests appear to be a bit flaky. Seems good to me, although I thought I upgraded everything last commit... oh well!


Cors headers on non OPTIONS

Is there any need to set cors headers on non options requests?

@kof closing @itsnotvalid is right


Make the JPEG/Zen mask tolerant of pure colors in band interleaved MRFs

The current behavior is that a zero on any band on input will result on zeros on all bands on output, since there is only one zero mask.  This leads to some saturated colors pixels in input to be converted to black.
Instead, the default behavior should be to only flag as black pixels that have at least one zero value in a band and relatively small values in the other bands (very dark pixels).  This would work better for most cases.
The original behavior (any zero masks the whole pixel) could be removed or made available via a JPEG specific create option.

This was done a while ago, the mask only flags the pixel as zero if all the bands are zero.


chore: update to Aspect Workflows 5.7.0-rc10

rc10 likely final

likely final
Famous last words :crossed_fingers:


Add ProdEx demo.

Cool! Glad we finally have one of these on the GitHub side!

LGTM. I assume that I could run this test app on my device, yeah?

Yeah.


Added composer.json

As requested here #7, i added composer support.
Before merging make sure to fix the "name" attribute in composer.json file

To include GluePHP trough composer add those lines to your composer.json
{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/jimmyfm/gluephp"
        }
    ],
    "require": {
        "jimmyfm/gluephp": "dev-master"
    }
}


Lite Concourse for existing Bosh Director

Changes in this PR include the configuration and documentation for a Lite Concourse deployment (1 VM) with an existing Bosh Director.
This approach can be useful when you want to leverage an existing Bosh environment but you don't need a full fledged Concourse deployment. Also, a Concourse Lite option for Bosh BootLoader, that already  facilitates the creation of the Jumpbox and Bosh Director.

@jaimegag , so in the existing Lite Concourse, we currently cannot use existing BOSH director ? Is that right? If yes, do we have to use a 'cluster' option to leverage existing BOSH director ?
Thanks so much!!!

Hey @jaimegag , wondering, you mentioned You don't have to use a cluster option to leverage an exiting Bosh Director., I thought using this repo, there are only two ways of deployment:

lite
cluster

Since lite deployment does not support BOSH director integration, I thought the only other way is to go with cluster, no ?
Thanks again for clarification!!!

Hey, thanks for working on this this! :slightly_smiling_face: Sorry for the delay.
I think this is useful but I'm worried about doubling all the effort from the cluster/ deployment and its ops files, which is where almost all PRs are submitted to. It seems like all ops files would be relevant to both deployment schemes, so it'd be a constant race to keep them in sync them as the ops files can't be reused for both (they use paths like /instance_groups/name=web). I see this PR has replicated a few of the common ones, but to be honest they all are kind of relevant, and more ops files are being PR'd in each week.
Even lite/ is a bit of an afterthought these days, and I don't know if anyone still uses it. We originally had it as a fast-and-easy way to deploy a Concourse, but we've since shifted away from BOSH for 'quick start' material in favor of Docker Compose.
It would be really nice if there was a way to do this by leveraging the already-existing cluster/ manifests/ops-files instead. Would it be possible to create a tool for converting a multi-instance_group manifest to a single-instance_group manifest? Maybe we could even leverage this to eliminate lite/, thereby consolidating everything into one manifest and set of ops files to maintain. (Or we could just remove lite/ outright and see if anyone complains. :grimacing:)
The README for this repo already says it's community-maintained with no guarantees, so I could just punt and merge this in, but I figured this is worth thinking about or at least acknowledging the increased risk. :thinking: Not trying to explode the scope of your PR!


Merge staging into production, 14 Aug 2024

To Test:

[x] Change links under Resources menu and add link to procedures manual by @dchiller in https://github.com/DDMAL/CantusDB/pull/1557
[ ] Escape special characters in suggested chant data by @lucasmarchd01 in https://github.com/DDMAL/CantusDB/pull/1561
[ ] Big Source Changes, Much Improvements, Wow. by @ahankinson in https://github.com/DDMAL/CantusDB/pull/1545
[ ] Add command to reassign feast data and update chants by @lucasmarchd01 in https://github.com/DDMAL/CantusDB/pull/1564
[ ] Fixed: A follow-up to the source rework by @ahankinson in https://github.com/DDMAL/CantusDB/pull/1566
[ ] Change help text for date field in Source model. Black formatting changes by @lucasmarchd01 in https://github.com/DDMAL/CantusDB/pull/1567
[ ] Fixed: Migrating alternate names by @ahankinson in https://github.com/DDMAL/CantusDB/pull/1568
[ ] Further fixes for institution migration by @ahankinson in https://github.com/DDMAL/CantusDB/pull/1570
[ ] Display additional chant fields on Chant Detail page when they exist by @dchiller in https://github.com/DDMAL/CantusDB/pull/1573
[x] Add legacy logos for acknowledgements page by @lucasmarchd01 in https://github.com/DDMAL/CantusDB/pull/1574
[x] Change instances of "Differentia Database" to "Differentiae Database" by @lucasmarchd01 in https://github.com/DDMAL/CantusDB/pull/1575
[ ] Put view classes in separate files by @dchiller in https://github.com/DDMAL/CantusDB/pull/1563
[ ] Add country and source columns to browse sources table by @dchiller in https://github.com/DDMAL/CantusDB/pull/1578
[x] Add indexing notes search to chant search page by @lucasmarchd01 in https://github.com/DDMAL/CantusDB/pull/1576
[ ] Add many-to-many segment field to source model by @dchiller in https://github.com/DDMAL/CantusDB/pull/1577
[x] Fix populate_diff_id_fields management command by @lucasmarchd01 in https://github.com/DDMAL/CantusDB/pull/1580
[ ] Chant create: optimize suggested chants feature by @dchiller in https://github.com/DDMAL/CantusDB/pull/1579
[ ] Update URLs, models, codebase, and admin pages to use "service" instead of "office" by @lucasmarchd01 in https://github.com/DDMAL/CantusDB/pull/1582
[ ] New: Add source key filter to chants by @ahankinson in https://github.com/DDMAL/CantusDB/pull/1584
[ ] New: Add views for institutions by @ahankinson in https://github.com/DDMAL/CantusDB/pull/1586
[ ] Make "Country" and "Source" columns sortable on Source List page by @dchiller in https://github.com/DDMAL/CantusDB/pull/1592

Has the command to reassign feasts in #1564 already been run? I noticed they've already been reassigned and deleted before I ran the command.

Has the command to reassign feasts in #1564 already been run? I noticed they've already been reassigned and deleted before I ran the command.

Hmm...I don't think I ran it. At least, I shouldn't have.

Also, I'm just about to run #1580

Nice! 🤞

Has the command to reassign feasts in #1564 already been run? I noticed they've already been reassigned and deleted before I ran the command.

Wait it looks like you ran it: https://github.com/DDMAL/CantusDB/issues/1560#issuecomment-2269241101

Wait it looks like you ran it: #1560 (comment)
😉

🤦♂

Ok, because these changes do a bunch with the sources and institutions, I'm gonna email everyone to take a look too. For example, at this page: https://staging.cantusdatabase.org/sources/.
I know that Debra also wanted #1583, but that could come in a future release.

Ok, because these changes do a bunch with the sources and institutions, I'm gonna email everyone to take a look too. For example, at this page: https://staging.cantusdatabase.org/sources/.

Good idea!

I know that Debra also wanted https://github.com/DDMAL/CantusDB/issues/1583, but that could come in a future release.

We can also try and quickly push this feature to staging. I assumed we'd have to do another merge of develop into staging before the release anyways.

@lucasmarchd01 I am getting a 404 on flatpages on staging...are you?

@lucasmarchd01 I am getting a 404 on flatpages on staging...are you?

Interesting... I can access the flatpages when I'm logged out, but once I log in I'm getting the 404.

Interesting... I can access the flatpages when I'm logged out, but once I log in I'm getting the 404.

Ah ok, I didn't realize it but that's exactly what's happening with me too.

Sounds good to me. Exciting that we're finally getting these changes up, thanks for all your hard work!

Thank you! And thanks @ahankinson! I'll start shortly.


Will my Gateway URL change?

Currently Virtual network setting is "OFF" for my APIM. I am planning to change it to external or internal. However, my customers already using "gateway" URL in the field.   Does the URL of my APIM endpoint change?   I am basically want to enable it to protect my APIM from DDoS attacks.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 8d854b3c-f9f9-7f6a-f889-e19acac2961c
Version Independent ID: ed544e54-d24b-2f37-05b6-8b60eacd2026
Content: How to use Azure API Management with virtual networks
Content Source: articles/api-management/api-management-using-with-vnet.md
Service: api-management
GitHub Login: @vladvino
Microsoft Alias: apimpm

Thanks for the feedback! We are currently investigating and will update you shortly.

@codemaker The gateway URL will not change when turning on virtual networks but whether it is exposed to the public internet by default depends on the mode that you are changing it to.
In case of the external mode, no further action is required to expose the gateway endpoint.
In case of the internal mode, you will have to both setup the DNS Records and configure an Application Gateway to expose the endpoints to the internet.

@codemaker Just following up here... Hope my previous comment clears things up.

Thanks for the response.  Once I enable external mode, do I need to manually set up monitoring on the VNET? Basically I would like to stop DDoS attack on APIM.

@codemaker Azure DDoS Basic is available for all azure services by default at no extra cost. When deployed into a VNET, you have the ability to enable Azure DDoS Standard Protection which provides you with addition mitigation capacilities.
You can read more about Best Practices of DDoS Protection in the official docs.

Standard protection cost $2000 plus per month.
"Azure DDoS Basic is available for all Azure services by default at no extra cost." - Do we have any Microsoft document for reference which says its free?

@codemaker The table in this doc does mention it.
Note this covers common network-level attacks by default. So, if you are using Azure, you are already covered by the free DDoS Protection.

Do we get DDoS attack dash board so that we can do daily monitoring? Basically we have APIM, Azure AD and Log Analytics which are publically exposed to the internet. do we really need to recure it or Microsoft will take care?

@codemaker Those metrics and logs are streamed to Azure Monitor when you have DDoS Standard as mentioned in the doc. The Basic Plan has not such metrics but will protect Azure Resources from common network-level attacks on its own.
You could still monitor you own services with metrics they each may provide for any anomalies that Azure DDoS may not consider an attack but are unusual for your application.

So the conclusion is adding external or internal mode will not help unless I apply a DDoS plan on VNET. Just leave APIM as it is will also be protected by basic Microsoft protection layer.

@codemaker Yes. That is correct for DDoS.

@codemaker Just following up here... Hope my previous comment clears things up.

Yes, we can close the thread/

@codemaker Glad we could help!
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Add Page Which Lists User Raised Issues

Build a page which only digital super users can see that displays a table of bug reports in descending order of when they were created (newest first).

Is this not what the ZH page displays?

@nickaddy I guess the idea is that this page would be a catchall in case any of the api calls fail and there is a disconnect between what's in the repo and what's in our database.

@nickaddy we should have a chat about this to decide whether to remove the ticket or not


Merge beta to master

Prevent people to get the old version when they install without specifying the version

:tada: This PR is included in version 1.0.0-beta.11 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


scroll down progressbar

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
scroll down progress bar enhances the UI of website
Use Case
https://github.com/VaibhavArora314/StyleShare/assets/169196836/bb3d999d-35be-4f5c-8fd5-b60531b5caaa
Benefits
No response
Add ScreenShots
No response
Priority
Low
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

so you want to implement the red progress bar on the top? but our website has a navbar so will it look good with it?

colour will be according to the background of your website it will not be red

Hi ,@VaibhavAorai314 if this issue is not completed ,can you assign me under gssoc'24.

@paulkrishanu4 any updates?


Growing coverage for some rules

I've dropped some checks because I didn't find cases for them.
Strongly need review.

Coverage remained the same when pulling 04e40f3cb2dc59d667ffbe94651ef92cc3dc1053 on zxqfox:hotfix/coverage-growing into 97f30d493c1b497275a5c6ea21aee3a42e5cd839 on jscs-dev:master.

Coverage remained the same when pulling 04e40f3cb2dc59d667ffbe94651ef92cc3dc1053 on zxqfox:hotfix/coverage-growing into 97f30d493c1b497275a5c6ea21aee3a42e5cd839 on jscs-dev:master.

Actually, those files are already 100% covered according to coveralls. What are you using to see coverage locally?

Actually, those files are already 100% covered according to coveralls.

I've just ran npm run coverage-html ;-)
These conditions marked yellow, and I think this information doesn't placed in lcov and these statements marked as covered. But actually it's overkill.

Would you please try and use our assertion methods?

Assertions: https://github.com/jscs-dev/node-jscs/blob/master/lib/token-assert.js
Example: https://github.com/jscs-dev/node-jscs/blob/master/lib/rules/disallow-space-before-binary-operators.js

@mdevils Yeah, why not.
What if there is no prevToken? It will be a uncaught error at lib/token-assert.js#L124

Feel free to fix that check.

@mdevils Okey. I had tried to find test cases before. Can you please provide some ideas how to test these cases.

In this case — no idea.
If you want to test tokenBefore with no prevToken, you can pass the first document token.

So I'm not sure but feels like we just don't need that check. ;-\ Okay. I'll rewrite these rules with token-assert. Thanks!

That check is needed in tokenBefore, not outside of it. So its easy to add and write a test.

@mdevils There is a problem with comments between tokens. Should I inject comments search logic into .whitespaceBetween and .noWhitespaceBetween functions?

Which problem did you face?

@mdevils /* comment */ if /* yolo */ ( /* another */ condition /* more */) /* again */ { // etc
Should whitespaceBetween ignore them? Should it count spaces outside of comments between tokens?

@mdevils I suppose to use a helpers getCommentAfter/BeforeToken to get the closest comment for token. It simplifies a lot inner rule code for a bunch of rules. https://github.com/zxqfox/node-jscs/commit/7a86811c61e29ec8b47cd309a3c6a6bb349441b9

Coverage increased (+0.06%) when pulling 065f1e041ceb5f08cf10ea9d10d409184c9f5dd1 on zxqfox:hotfix/coverage-growing into 93f0944dd89ccb17d93f48271f5d728303cb968a on jscs-dev:master.

LGTM.
@markelog, please take a look.

Still a WIP?

Fixed last nuts. Thanks for review, guys!
/cc @markelog

Coverage increased (+0.06%) when pulling 7504edec95bf432bcddba5d7885cf88f883ebb10 on zxqfox:hotfix/coverage-growing into 06fadf9d337d713178ce8c791e68090825075a2e on jscs-dev:master.

Cudos for this hard work!


The bot is not catching up copilot.vim releases anymore

Copilot.vim has run away and the last release caught by the bot is 1.10.2.
There is a problem with the bot.

@zerolfx ,

I tested on my daily use case, not extensive tests.
I will be honoured to try to continue your work.


Feature/section classname

Description
Modified the section field template to use FormFieldSection in order to pass cssClass to the fieldset element and be able to customize the styles for it.
Motivation
Event though the sections in the form editor allow for setting a css class, it does not pass it down to the component.
Sitecore Case nr.: CS0178480
How Has This Been Tested?
a forms was created in the forms editor. Added classes to sections. Was able to verify the fieldset gets the class assigned

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

Checklist:

[x] I have read the Contributing guide.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.

@kamsar @anastasiya29 could you please review this one ASAP dou to the fact we faced with this issue on client's project? Thanks!

@kamsar @anastasiya29 Any updates on this?

@martinarias, @VadzimPapko I reviewed. Everything is fine i'll merge.

@sc-illiakovalenko thank you! Good news!


JioCinema

Details

Service Name: JioCinema
Service URL: https://www.jiocinema.com/
Is it region-locked? If yes, to what region? Not sure, but works in India
Does it have a free version / trial? Yes

Additional Information

Issue already exists. Sorry for duplicate. https://github.com/trakt-tools/universal-trakt-scrobbler/issues/365


Fix compatibility with browser in Live 12.1 Beta

Patch for Ableton Live 12.1 Beta compatibility. This fixes the menu selection function of LES to be compatible with the browser functionality changes made by Ableton for the 12.1 Beta release. Instead of "down arrow" followed by "enter" it triggers "enter", followed by "enter". This patch also adds a following function that automatically closes the browser view after a menu item is loaded by triggering the new Live 12 keyboard shortcut, "CMD+Option+5" for browser view toggling.

Thank you for your contribution 🎉 !
I've updated develop to be based on v1.3.4.beta.3 (at the time of opening, it was based on v1.3.4.beta.2) as beta.3 has routines you can use to get the version of Live (source) and apply the fix for only Live 12 and above.
Please rebase your changes on top of develop and gate the patch for Live 12 only.

My apologies but I'm more of an enthusiast than an actual dev with no real experience with contributing to repos. If anyone wants to grab the ball and run with it at this point that would be awesome to support LES. I couldn't figure out the best way to add the condition to have this change to only apply to Live 12 and above.
I do believe that "return, return" would work with previous Live versions just as well compared to the original execution of "down, return" - however, I realize that the "close browser" keyboard shortcut only applies to Live 12 which would still be relevant for my contribution.
If anyone is interested, I made a release on my fork that works for Live 12.1 beta and is running stable on Mac OS 14.5 (Sonoma).

Credit to reddit user NIELS_ON
Reference:
https://www.reddit.com/r/ableton/comments/1bbr6xk/the_live_enhancement_suite_has_been_discontinued/


format_datetime ignores date/time format with IntlDateFormatter prototype

I originally described this issue in https://github.com/twigphp/Twig/issues/3568#issuecomment-931382860 but have created this PR to keep the discussion focussed.

Installed this project and all my servers went off. Very good one. Thank you

This is a read only, can you move this PR to the main Twig repository? Thank you.


SubscriberStatelessServiceBase

Added SubscriberStatelessServiceBase class to simplify managing Stateless Service subscribers.
Abstracts boilerplate work of subscribing to messages and exposing endpoints for subscribing and unsubscribing.
Provides a simple mechanism to accept and handle multiple message types.

Thanks for this contribution. I've changed your code a bit to use the PayloadSerializer.
Also thought of a way to make subscriptions declarative, instead of imperative.
Please let me know your thoughts on this. We can do the same for stateful services.

My attempts at implementing the SubscriberServiceBootstrap did not go well.  As far as I can see, we don't have any good way to know if a given service is a subscriber service.  The ServiceProxy itself doesn't know anything about the service, it was created based on an interface and location that the user provides and doesn't necessarily match the actual service.  It might be possible if we have an operation on ISubscriberService to return the service's interface type which would define handler methods annotated with Subscribe attributes.  There are more details to figure out, but it would definitely require that the Broker has knowledge of all the service interfaces and event types, which I would really rather not do.
Also, I was thinking about ISubscriberStatelessService.  I created it for use with SubscriberStatelessServiceBase that added the SubscribeAsync and UnsubscribeAsync endpoints.  I'm wondering, should these be added to ISubscriberService so all subscribers have these endpoints, or perhaps we don't need these at all?  They are a pass-through to the Broker, so maybe it is possible to call the Broker service directly.  What do you think?

Why not go with property manager from sf, like in broker, for subsriber to register itself? Meta can be serilized json but keep it small, then it's easy to discover subsriber service from broker service, also you clould put inside meta supported message types? Or base subsriber interface could also have something like taks getsupportedmessages which can be called by broker to register it for those messages

My point is that the Broker cannot know anything about the subscriber service without asking it.  Labels would probably work, but the opinion over here is that would not be a very intuitive experience for the developer.  It also may not be flexible enough for all use cases.  The complex situation we are thinking of is when a Stateful subscriber service wants to choose whether or not it wants to subscribe to a message type based on which partition it is on.
I'm not sure that having the Broker look for subscriber services simplifies anything.  The Broker still needs to call to the subscriber to get subscription information.  The subscriber still needs to set up handlers and gather information about which message types it wants to subscribe to.  On a positive note, I was able to move the handler discovery logic to the SubscriberServiceHelper, so it will be reusable in Stateful subscriber services.
I definitely agree that it feels unnatural to have an endpoint that just passes the subscribe or unsubscribe request through to the Broker when we could just call the Broker service directly.  Currently, the RegisterServiceSubscriberAsync endpoint takes a ServiceReference object.  Will the Broker be able to detect all the things it needs to build the ServiceReference properly (i.e. partition, listener)?  Will it be challenging to craft the ServiceReference consistently when sometimes it is registered by the Broker and sometimes the request comes from the subscriber?  If we are not careful with the comparison logic, we may end up with duplicate subscriptions.  Probably the new ISubscriberService endpoint would have to return the ServiceReference along with the list of message types.  Then we have just created a bulk subscribe action, which is not bad, but I'm not sure it gets us much.  Whether that action is initiated by the Broker or the Subscriber service doesn't seem to make much much difference.

Doing some more investigation, I found that ServiceFabric properties can be created dynamically, so maybe there is still hope for that idea.

Would you mind elaborating a little on the dynamic properties?

Sorry for slow response, I'm out of town for a few days.
I was able to use https://docs.microsoft.com/en-us/dotnet/api/system.fabric.fabricclient.propertymanagementclient.putpropertyasync?view=azure-dotnet#System_Fabric_FabricClient_PropertyManagementClient_PutPropertyAsync_System_Uri_System_String_System_String_ to add a property on the subscriber Service Fabric service from the OnOpenAsync() call and read that property from the Broker, also using the PropertyManagementClient.
Potentially, the subscriber service could build some meta data about itself, probably mostly drawing from the Subscribe attribute, and store that meta data in a property.  The broker could read that property to know if the service is a subscriber and which message types to subscribe to.
I'm not sure if there is a notification that can be triggered to alert the Broker that a property has changed.  If not, that could be a problem.

I've thought of a way to auto register subscribers without adding much complexity. Check the latest push. I think that could work. Any thoughts?

You have used the bootstrapper as a factory to create the Service instance and register subscribers in one step.  If you could create an easy to use factory that would set everything up and not need a base service class anymore, then I think this would be an interesting approach.  But I don't think that is going to work out.  With this approach, we still need to get the collection of SubscriptionDefinitions to the Service and implement ReceiveMessageAsync() to call the appropriate handler.
This seems more complex than subscribing in OnOpenAsync() since the implementer needs to do setup work in two places now, Program and the Service class.  Did you see my previous commit where I moved most of the logic into SubscriberServiceHelper?  A lot of it got reverted in your "merge down master" commit.  We can move all the subscription logic into SubscriberServiceHelper so it can be reused for a SubscriberStatefulServiceBase.  That should be pretty simple to use.

See my latest commit.  I moved all logic into the SubscriberServiceHelper.  I currently have the SubscriptionDefinitions stored in the helper.  I'm not sure if I like that.  It may be better to store that in the base class so the helper doesn't need to maintain any state.  I also played around with an idea to have the caller send a ServiceReference object instead of itself to minimize having to create two versions of everything in order to support Stateless and Stateful services.  Let me know what you think.

I propose we separate the responsibilities of subscribing and method invocation.
Using the factory delegate doesn't require using a base class, nor any implementation on the end-user side, it only requires a Stateless or Stateful service from the SF SDK and the interface ISubscriberService. The factory class will do all the hard work of discovering attributes on the service instance and register subscriptions. The logic of invoking the correct method when a message arrives can be separated from the process of subscribing, by introducing a helper. You'd keep the subscription defs in memory as part of the service composition, but not its base. The helper would be injected by the bootstrapper.
We can delete the SubscriberStatefulServiceBase class and only require a opt-in or opt-out mechanisms for auto-registration and auto-invocation. E.g. by using a service class attribute.
My apologies for the destructive merge, that was unintended and messy.

So, usage for the bootstrapper approach would look something like this:
public class MySubscriberStatelessService : StatelessService, ISubscriberService
{
    private readonly ISubscriberServiceHelper _subscriberServiceHelper;

    protected SubscriberStatelessServiceBase(StatelessServiceContext serviceContext, ISubscriberServiceHelper subscriberServiceHelper)
            : base(serviceContext, subscriberServiceHelper)
    {
    }

    public Task ReceiveMessageAsync(MessageWrapper messageWrapper)
    {
        return _subscriberServiceHelper.ProccessMessageAsync(messageWrapper);
    }

    protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
    {
        return this.CreateServiceRemotingInstanceListeners();
    }

    [Subscribe(typeof(TestMessage))]
    private Task HandleTestMessage(TestMessage testMessage)
    {
        // TODO: handle message
    }
}

This assumes the bootstrapper somehow made the helper aware of the SubscriptionDefinitions so SubscriberServiceHelper.ProcessMessageAsync() is able to route the message to the proper handler.
Then in Program.cs, we have to modify the service registration to something like this:
ServiceRuntime.RegisterServiceAsync("Financial.EventHandler.ServiceType",
    context => new StatelessSubscriberServiceBootstrapper<Service>(context, ctx => new Service(ctx, new SubscriberServiceHelper())).Build())
    .GetAwaiter().GetResult();

Using the base class, it would be something like this:
public class MySubscriberStatelessService : SubscriberStatelessService
{
    protected SubscriberStatelessServiceBase(StatelessServiceContext serviceContext)
            : base(serviceContext)
    {
    }

    [Subscribe(typeof(TestMessage))]
    private Task HandleTestMessage(TestMessage testMessage)
    {
        // TODO: handle message
    }
}

And service registration is simply the generated default.  My goal is to make this a simple as possible to use.  In this case, the implementer doesn't need to deal with ISubscriberServiceHelper directly.  Boilerplate setup is handled automatically.
Can you explain why you would like to avoid having a base class?  It really helps simplify usage.  Yes, we would need a separate base for Stateful and Stateless, but all the logic is in the helper, so that's not a big deal.  The bootstrapper needs two implementations as well.  The only issue I can think of is if the service needs to implement another base class for some reason.  That seems like it would be rare and the solution would be to use the helper to manually subscribe and process messages.  That worst case situation would be only one additional method call more than the best case of the bootstrap approach.
I think having the ability opt-out of subscribing, as you mentioned, is useful, but probably rare.  Maybe an attribute on the service class like [AutoSubscribe(false)].  A StatefulService may use such a feature to decide whether or not to subscribe based on which partition it's on.  I don't think an opt-out for auto invocation makes sense because the user explicitly opts in by using the Subscribe attribute.  Besides, it doesn't hurt to register handlers that will never be invoked because we never subscribed to that type.

That's a solid argument. I favor composition over inheritance to allow maximum flexibility at the end-user side, but indeed this comes at the price of adding some complexity. So why don't we meet in the middle, and offer both the base class (using the helper) and the bootstrapper + helper? It doesn't require a lot more than what is here now.
So it would become:
public class MySubscriberStatelessService : SubscriberStatelessService
{
    protected SubscriberStatelessServiceBase(StatelessServiceContext serviceContext, ISubscriberServiceHelper subscriberServiceHelper = null)
            : base(serviceContext, subscriberServiceHelper)
    {
    }

    [Subscribe(typeof(TestMessage))]
    private Task HandleTestMessage(TestMessage testMessage)
    {
        // TODO: handle message
    }
}

Passing ISubscriberServiceHelper to the ctor to allow mocking and unit testing.

In the SubscriberStatelessServiceBase, the ISubscriberServiceHelper is an optional argument in the constructor, so implementers have it available if they need it for testing or anything else, but don't have to provide it if they don't need it.
I agree, composition is preferable over inheritance when possible.  I think we achieved that goal by moving all logic into the helper.  The base class provides a convenient wrapper to abstract away the plumbing, but it is not required.  It is easy enough to use the helper directly instead of the base class when maximum flexibility is required.  In that case, I think it is more simple to subscribe in the service manually rather than setting up a bootstrapper to do it automatically.  At least everything would be in one place.
I tested the SubscriberServiceBootstrapper (with a couple modifications to get it working) and ran into a problem.  It turns out, at the time the service is instantiated, the "Partition" property on the service is not set yet.  When we try to create the ServiceReference so we can subscribe, we get a null reference exception.  We could do handler discovery in the bootstrapper, but it looks like subscribing will have to happen in OnOpenAsync().

@loekd, looking forward to your feedback on the latest changes.  We are eager to wrap up this task.

I've added some code, and the bootstrapper now works. I found out that the SubscriberStatelessServiceBase doesn't unregister itself when it moves, or is shutdown at this time.
Once that is in place, we can merge this.

We are intentionally not unregistering.  If a service moves or goes down for any reason, we want the Broker to continue to queue up incoming messages and deliver them when the service becomes available again so we don't lose any messages.  We are thinking services should be manually unregistered via some Broker management console.

Alright, makes sense.
I've pushed my final changes. When you agree, I'll push the merge button.

I added a base class for stateful services and updated the documentation accordingly.  I'm ready to merge.

The new version is released. Thanks @danadesrosiers  for all the hard work. I really like these improvements.


Add CreateLocation to app proto

Adds the CreateLocation call to the app.proto to allow creation of locations via gRPC

@edaniels I ran make dist/buf and am not seeing any changes on my machine.

@edaniels @stevebriskin I ran make dist/buf and am not seeing any changes on my machine.

Just needed to run make setup again.


reward converter - add trade route ID to portId

Context
We need to have a separate trade ICA for each trade route. Otherwise, if two trade routes shared a common denom, it could interfere with the queries.
Brief Changelog

Added FormatTradeRouteICAOwner and FormatTradeRouteICAOwnerFromAccount
Renamed FormatICAAccountOwner to FormatHostZoneICAOwner
Updated trade route ICA owners to use the new function
Added unit tests for the relevant types functions

NOTE: @ethan-stride, I'm not really loving the implementation of these owner functions. Curious if you can think of a better way to do it

@ethan-stride what are you thoughts on the FormatTradeRouteICAOwnerFromAccount? Does it make sense to pass the full account or instead do
func FormatTradeRouteICAOwnerFromAccount(chainId, tradeRouteId string, icaAccountType ICAAccountType) string {
	return fmt.Sprintf("%s.%s.%s", chainId, tradeRouteId, icaAccountType.String())
}

it would muddy the invocation a bit
// from
owner := types.FormatTradeRouteICAOwnerFromAccount(route.GetRouteId(), route.TradeAccount)
// to
tradeAccount := route.TradeAccount
owner := types.FormatTradeRouteICAOwnerFromAccount(tradeAccount.ChainId, route.GetRouteId(), tradeAccount.Type)

But it would be a little more explicit about which fields are used instead of having to know that the ICAAccount struct needs both chainId and type filled out

@ethan-stride what are you thoughts on the FormatTradeRouteICAOwnerFromAccount? Does it make sense to pass the full account or instead do
func FormatTradeRouteICAOwnerFromAccount(chainId, tradeRouteId string, icaAccountType ICAAccountType) string {
	return fmt.Sprintf("%s.%s.%s", chainId, tradeRouteId, icaAccountType.String())
}

it would muddy the invocation a bit
// from
owner := types.FormatTradeRouteICAOwnerFromAccount(route.GetRouteId(), route.TradeAccount)
// to
tradeAccount := route.TradeAccount
owner := types.FormatTradeRouteICAOwnerFromAccount(tradeAccount.ChainId, route.GetRouteId(), tradeAccount.Type)

But it would be a little more explicit about which fields are used instead of having to know that the ICAAccount struct needs both chainId and type filled out

From discussion on Slack:  being explicit about which fields from the account are going into the function call makes it harder to mistakenly pass in an account which is not yet initialized without realizing it.  This makes the function clearer but calling it slightly more work -- overall a tradeoff which is probably worth it so the new proposed function params make sense.

LGTM I think it is ready


[go] returns writer.Close error to caller when writing parquet

Describe the bug, including details regarding any error messages, version, and platform.
Currently, when writing parquet a parquet file, if writer.sink.Close() reports an error, it is not handled and returned by writer.Close(). This could cause a broken pipe with silenced error.
Component(s)
Go

PR incoming


bug in bigbench hard tutorial example?

The tutorial example at https://microsoft.github.io/Trace/examples/nlp/bigbench_hard.html seem to contain two bugs (one being more of a typo because it does not affect the training):

The optimizer registers twice the prompt as parameters to be optimized

optimizer = OptoPrime(dp.parameters() + [dp.prompt_template], config_list=autogen.config_list_from_json("OAI_CONFIG_LIST"))

In the model architecture, the model is called with prompt_template.format(question) inside the bundled layer create_prompt. The problem is that .format is a function call and thus the ParameterNode is recorded as a intermediate node instead of a root node. Why is that a problem? it seems that the opto optimizer only optimizes ParameterNode that are root node, as a result, instead of recording the prompt_template inside the graph as the ParameterNode it records it question (which is a root node) as the variable inside self.prompt_template.

One could potentially fix 2 by defining the prompt as a str instead of ParameterNode directly inside the bundled function

Hi @linyuhongg, thanks for raising this issue!
To point 1, nice catch -- the code was first written with an older version of the library. This part will be fixed.
To point 2, I'm not sure I fully understand. Can you run the following code:
task = "sports_understanding"
train = load_dataset("maveriq/bigbenchhard", task)["train"]
examples = [{"question": r["input"], "answer": r["target"]} for r in train]

dp = Predict()
optimizer = OptoPrime(dp.parameters(),
                                    config_list=autogen.config_list_from_json("OAI_CONFIG_LIST"))

GRAPH.clear()
response = dp.forward(examples[0]['question'])
response.backward("success", visualize=True)

I think prompt_template is still a root node.

I think the problem steems from the fact that response.backward("success", visualize=True) builds a different TraceGraph than the optimizer TraceGraph

Hi @linyuhongg, thanks for attaching the output!
If you look at the #Others, it starts with (str) eval0 = ..., this is actually the output of create_prompt -- a system prompt that has the correct question filled in, not the original system prompt that should be optimized.
I wonder if you error is caused by not running this with the new optimizer = OptoPrime(dp.parameters()), because after running this code:
task = "sports_understanding"
train = load_dataset("maveriq/bigbenchhard", task)["train"]
examples = [{"question": r["input"], "answer": r["target"]} for r in train]

dp = Predict()
optimizer = OptoPrime(dp.parameters(),
                                    config_list=autogen.config_list_from_json("OAI_CONFIG_LIST"))

for step, example in enumerate(examples):
    GRAPH.clear()
    response = dp.forward(example['question'])
    correctness = eval_metric(example['answer'], response)

    feedback = "correct"

    optimizer.zero_feedback()
    optimizer.backward(response, feedback)

    optimizer.step(verbose=True)
    break

I get:
#Instruction
You need to change the <value> of the variables in #Variables to improve the output in accordance to #Feedback.

#Code
eval0 = eval(self=ModelWrapper0, prompt_template=str3, question=str0, __code=__code1)
LLMCallable.call_llm0 = LLMCallable.call_llm(self=ModelWrapper1, user_prompt=eval0)
eval1 = eval(self=ModelWrapper2, prompt_template=str3, question=str1, response=LLMCallable.call_llm0, __code=__code0)

#Documentation
[eval] This operator eval(__code, *args, **kwargs) evaluates the code block, where __code is the code (str) and *args and **kwargs are the arguments of the function. The output is the result of the evaluation, i.e., __code(*args, **kwargs).
[LLMCallable.call_llm] .

#Variables
(str) str3=
Given the fields `question`, produce the fields `answer`.

---

Follow the following format.

Question:
Answer:

---
Question: {}
Answer:

(code) __code1:def create_prompt(self, prompt_template, question):
        return prompt_template.format(question)
(code) __code0:def extract_answer(self, prompt_template, question, response):
        answer = response.split("Answer:")[1].strip()
        return answer

#Constraints
(code) __code1: The code should start with:
def create_prompt(self, prompt_template, question):
(code) __code0: The code should start with:
def extract_answer(self, prompt_template, question, response):

#Inputs
(ModelWrapper) ModelWrapper2=<opto.trace.modules.model.<locals>.ModelWrapper object at 0x158760220>
(str) str1=Is the following sentence plausible? "Elias Lindholm beat the buzzer."
(ModelWrapper) ModelWrapper1=<opto.trace.modules.model.<locals>.ModelWrapper object at 0x158760220>
(ModelWrapper) ModelWrapper0=<opto.trace.modules.model.<locals>.ModelWrapper object at 0x158760220>
(str) str0=Is the following sentence plausible? "Elias Lindholm beat the buzzer."

#Others
(str) eval0=
Given the fields `question`, produce the fields `answer`.

---

Follow the following format.

Question:
Answer:

---
Question: Is the following sentence plausible? "Elias Lindholm beat the buzzer."
Answer:

(str) LLMCallable.call_llm0=Question: Is the following sentence plausible? "Elias Lindholm beat the buzzer."
Answer: Yes, the sentence is plausible. In the context of sports, "beat the buzzer" typically means that an athlete, such as Elias Lindholm, scored right before the time expired in a period or game.

#Outputs
(str) eval1=Yes, the sentence is plausible. In the context of sports, "beat the buzzer" typically means that an athlete, such as Elias Lindholm, scored right before the time expired in a period or game.

#Feedback
correct

Hi @linyuhongg, thanks for attaching the output!
If you look at the #Others, it starts with (str) eval0 = ..., this is actually the output of create_prompt -- a system prompt that has the correct question filled in, not the original system prompt that should be optimized.
I was able to recreate your bug! It's caused by:
@model
class A:
  def __init__(self):
    self.text = ""
    self.text = ParameterNode(self.text, trainable=True)

I pushed a fix for the BBH example. So if you do:
prompt_template = dedent("...")
        self.prompt_template = ParameterNode(prompt_template, trainable=True,
                                             description="...")

It will work fine.
We are working on a solution to fix the deeper bug. Thanks for pointing this out!

I updated my comment and found the bug!! Sorry about the wait. Let me know if you see the correct outputs!

removing GRAPH.clear() fixes the solutions for me.
If I understand correctly: the class initialization automatically register its nodes into the GRAPH. Upon clearing the GRAPH, the forward pass recreates intermediate nodes during the forward and registers them, since initial node prompt_template is only declared in during initialization, it is never registered again in the GRAPH.

Yes, your understanding is correct. I thought about adding some patching to the optimizer to address this partially, but right now, it's better to treat the py_name of each node as unique and don't call GRAPH.clear() after nodes are initialized.


[webview_flutter_android] Fix timeouts in the integration tests

Fixes timeouts caused by a race condition when loading a page. In pre-4.0 webview_flutter, the widget was passed the initial url, so we were able to call await pageLoads.stream.first; before the page was loaded.
However, these tests would load the url before we could call await pageLoads.stream.first;, leading to a timeout.
This could also be responsible for the test crashes, but I'll keep an eye on the CI to make sure.
Edit: Tests passed first time, so this could be the only fixed needed!
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
[x] I signed the CLA.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
[ ] I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

I tried to find a clever solution, but ultimately just gave up.
The problem is that these tests are using StreamController<String>.broadcast(); which doesn't buffer values. So if a url loads we get to the line await pageLoads.stream.first, the test timeouts.
My initial solution in https://github.com/flutter/plugins/pull/6857/commits/1d8ee9c7454bd8030e6eb4be368fca5aac5e899e just moved the loadRequest closer to the call of await pageLoads.stream.first which is admittedly a subpar solution.
My second solution in https://github.com/flutter/plugins/pull/6857/commits/c3458ac97ffeaa27d7b8eada0609514886c4148a removed the broadcast() constructor, but you can't listen to a non-broadcast stream more than once. (leaking is the reason based on what i've read)
Finally, I just gave up and switched to completers.

Looks like the iOS package and the app-facing package have the same test structure, so we should be sure those get updated as well.


Create Windows installer

People have been requesting this, so I created this issue as a response.
Ideally, the installer system that Google created should be used (if it is possible without using Google's pre-built binaries). Other installer systems must not be considered until it can be shown that Google's installer system has problems that another system solves.
I have no interest nor the time to implement this. I am open to anyone taking up this task.

I worked on that.
Created a simple installer creating script. For authors.
But what about signing them?
Code Signing Certificates are very expensive more than 150$ /year
I could easily self-sign them but that would still popup a warning that might scare users off.

You can use GPG to sign the installer file and provide the signature file as a separate download. This makes it easier for non-Windows users to sign binaries and upload them. We should discuss the signing system in more detail on Gitter or elsewhere.
Regarding the installer, I think there are scripts and tools to create installers. I know of mini_installer, but there may be others.

@Eloston : Henry updated its tool (chrlauncher) to install, update and launch ungoogled-chromium ;)
https://github.com/henrypp/chrlauncher/issues/33#issuecomment-279736691

Windows installers have been introduced a few versions ago at the time of writing.


Sourcemaps map to the wrong file/line in some situations

In bootstrap, the [class^="icon-"], [class*=" icon-"] is in sprites.less (line 17 in my version), but when compiling with Less.php the sourcemap is pointing to an unrelated line in tables.less.
A screenshot of Chrome showing the issue:

I'll try to put together a minimal test case that replicates this, I'm filing the issue now mostly a reminder to myself to do that, and if anyone else has more info they can drop it in here too.

Might be related to (or a dupe of) issue #192.


[models] Replace current tf mobilenetv3 implementation with tf.keras.applications implementation

Bug description

implementation is still troublesome on CPU (grouped convolutions)
is not ONNX exportable (some strange error messages)
cannot be pushed to the huggingface hub (raise with: model contains binary data - invalid model)

Hello Felix, I started working on this issue and i have some questions/remarks

Using the keras Implementation directly i can see that the mobilenetv3 small has a different number of parameters from the keras implementation compared to doctr implementation.
is the weights for mobilenetv3 the pretrained ones (from hub) or are weights trained by mindee?
if it's the second case should we use keras implementation but reconcile the model to have the same parameters as the one in doctr to be able to reload weights?  ( Doing that means reusing the InvertedResidual class)

These are some questions i kind of face when trying to look at it.
Feel free to give any other information or suggestions about it
Thank you

Hi @aminemindee :wave:,
nice that you have started to work on it :+1:
One thing in front of your questions we can solve this issue in a draft PR but have to wait before we merge it until 0.5.2 is released otherwise it would be a big breaking change for current users of doctr (why ? this change affects on TF side db_mobilenet_v3_large / crnn_mobilenet_v3_small / crnn_mobilenet_v3_large which needs to be retrained after changing the backbone)
Now your questions:

i think it makes more sense to compare the torchvision implementation we use in doctr and the keras one :)
trained from mindee ( with charactergenerator - see classification training script )
i would suggest to train these models from scratch (with mindee data) there is already an issue pinned for 0.6.0 #969

Additional to the backbone change we need to ensure that the above models continue to work well by testing them with toy runs
Let me know what you think :hugs:

Hi @aminemindee, are you still interested to solve this ? :) So we could assign it to you

Hi @aminemindee, are you still interested to solve this ? :) So we could assign it to you

Hello @felixdittrich92 i will get back to it once i finish a project i'm working on to make the detection model training part working with multiple classes and then maybe retrain with that so i can't really work on it at the moment.

sounds interesting :) Yeah no stress wouldn't make much sense before the 0.5.2 release is done

TODO steps:

[ ] replace mobilenet implementation in https://github.com/mindee/doctr/blob/main/doctr/models/classification/mobilenet/tensorflow.py with tf.keras.applications implementation
[ ] enable tests: https://github.com/mindee/doctr/blob/16633333fa8ffe4cd610a956fa6fc617046a5d95/tests/tensorflow/test_models_classification_tf.py#L101
[ ] update: https://github.com/mindee/doctr/blob/16633333fa8ffe4cd610a956fa6fc617046a5d95/doctr/models/detection/differentiable_binarization/tensorflow.py#L369
[ ] manual toy run tests for (only to ensure that the models work and train well - all checkpoints can be removed):
https://github.com/mindee/doctr/blob/16633333fa8ffe4cd610a956fa6fc617046a5d95/doctr/models/recognition/crnn/tensorflow.py#L275
https://github.com/mindee/doctr/blob/16633333fa8ffe4cd610a956fa6fc617046a5d95/doctr/models/recognition/crnn/tensorflow.py#L295
https://github.com/mindee/doctr/blob/16633333fa8ffe4cd610a956fa6fc617046a5d95/doctr/models/detection/differentiable_binarization/tensorflow.py#L348


Code in AlgebraicCoding.ipynb not commented

The code in the file AlgebraicCoding.ipynb is not well commented and does not have a great explaination.  More details need to be included here so students can understand the code that goes into the Bernoulli and SymmetricChannel classes.

Comments have been added to all parts of the code for this document.


Disable Channel badges for API 26 and lower

Fixes #131

I will merge this with the additional gating and comment - no need to add any more commits here.

Ah, just spotted this PR is made against the release branch, could you update it to be against the main branch as described in https://github.com/androidx/media/blob/release/CONTRIBUTING.md#pull-requests? I tried just changing it in the GitHub UI but it created a lot of conflicts - it may be easier to just open a new one and close this one?

Closing, see #141


Mix.extract compile empty CSS

Laravel Mix Version: 4.0.15
Node Version (node -v): 10.7.0
NPM Version (npm -v): 6.5.0
OS:

Description:
If i use extract with .sass at the exit  i get empty css file, in the second case i compile without extract, as a result => all Okey
I have`t dynamic import in project
Steps To Reproduce:
First step: yarn watch
npm script node node_modules/cross-env/dist/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --watch --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js
webpack.mix.js
mix.setPublicPath(path.normalize('themes/frontend/assets'));
.sass('themes/frontend/assets/sass/style.scss', 'dist/css')     .sass('themes/frontend/assets/sass/utils/_typografy.scss', 'dist/css')     .js('themes/frontend/assets/js/main.js', 'dist/js/')     .js('plugins/gotorussia/travels/assets/form.js', 'dist/experimental')     .js('themes/frontend/assets/js/map.js', 'dist/js/');
Case 1 (without extract) result:
Asset       Size                                          Chunks             Chunk Names
/dist/experimental/form.js    527 KiB                         /dist/experimental/form  [emitted]  /dist/experimental/form
/dist/js/main.js   7.66 MiB                                   /dist/js/main  [emitted]  /dist/js/main
/dist/js/map.js   4.24 KiB                                    /dist/js/map  [emitted]  /dist/js/map
dist/css/_typografy.css    270 KiB                                   /dist/js/main  [emitted]  /dist/js/main
dist/css/style.css    542 KiB                                   /dist/js/main  [emitted]  /dist/js/main
Case 2 (with extract()) result:
                 Asset       Size                            Chunks             Chunk Names
                                      /dist/js/manifest.js   11.5 KiB                 /dist/js/manifest  [emitted]  /dist/js/manifest
                                   dist/css/_typografy.css   15 bytes  /dist/js/main, /dist/js/manifest  [emitted]  /dist/js/main, /dist/js/manifest
                                        dist/css/style.css   15 bytes  /dist/js/main, /dist/js/manifest  [emitted]  /dist/js/main, /dist/js/manifest

Inside dist/css/style.css and /dist/js/manifest.js written: /* (ignored) */
Case 3 (with extract(['vue'])) result:
CSS empty
                                            Asset       Size                                             Chunks             Chunk Names
                                                                 /dist/js/manifest.js   11.9 KiB                                  /dist/js/manifest  [emitted]  /dist/js/manifest
                                                              dist/css/_typografy.css    0 bytes  /dist/js/main, /dist/js/manifest, /dist/js/vendor  [emitted]  /dist/js/main, /dist/js/manifest, /dist/js/ven
dor
                                                                   dist/css/style.css    0 bytes  /dist/js/main, /dist/js/manifest, /dist/js/vendor  [emitted]  /dist/js/main, /dist/js/manifest, /dist/js/ven
dor

Do you use dynamic import in your project?

also experiencing same issue. any resolution to this. Extract without specifying vendor packs results in an empty .css; If i specify vendor packs, .css results with "webpack_require" calls to specified vendor packs.

any solution ?

My solution..., build your own webpack:
/webpack.config.json
const os = require('os')
const path = require('path')
const chalk = require('chalk')
const notifier = require('node-notifier')
const TerserPlugin = require('terser-webpack-plugin')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const OptimizeCSSAssetsPlugin = require('optimize-css-assets-webpack-plugin')
const BuildNotifierPlugin = require('webpack-build-notifier')
const ManifestPlugin = require('webpack-manifest-plugin')
const { VueLoaderPlugin } = require('vue-loader')
const WebpackBundleAnalyzer = require('webpack-bundle-analyzer')
const BundleAnalyzerPlugin = WebpackBundleAnalyzer.BundleAnalyzerPlugin
const pkg = require('./package.json')

module.exports = (env, argv) => {
  const appName = 'Webserver'
  const appLogo = path.resolve(__dirname, 'public/img/icon.png')
  const dist = path.resolve(__dirname, 'public/dist')
  const cache = path.resolve(__dirname, '.cache')
  const platform = os.platform()
  const developerName = os.userInfo().username
  const ENV = argv.mode ? argv.mode : env.NODE_ENV
  const isProd = ENV === 'production'
  const isDev = ENV === 'development'

  notifier.notify({
    appName: appName,
    title: appName,
    message: 'Starting webpack compiler...',
    contentImage: appLogo,
    sound: true,
    icon: path.resolve(__dirname, 'public/img/webpack.png'),
  })

  console.log('nodeENV:', chalk.whiteBright(ENV))
  console.log('whoIsMe:', chalk.whiteBright(developerName))
  console.log('whichOs:', chalk.whiteBright(platform))
  console.log('devMode:', isDev ? chalk.green(isDev) : chalk.red(isDev), '\n')

  return {
    entry: {
      app: './resources/js/app.js',
      style: './resources/sass/app.scss',
    },
    target: 'web',
    devtool: isDev ? 'cheap-module-eval-source-map' : 'source-map',
    output: {
      path: dist,
      filename: isDev ? '[name].js' : '[name].[chunkhash].js',
    },

    resolve: {
      alias: {
        vue: 'vue/dist/vue.js',
      },
    },

    optimization: {
      concatenateModules: true,
      // namedModules: true,
      // namedChunks: true,
      usedExports: true,
      runtimeChunk: 'single',
      splitChunks: {
        cacheGroups: {
          vendors: {
            test: /[\\/]node_modules[\\/]/,
            reuseExistingChunk: false,
            chunks: 'all',
            name: 'vendors',
          },
        },
      },
      minimize: isProd,
      minimizer: [
        new TerserPlugin({
          extractComments: 'some',
          sourceMap: false,
          cache: cache,
        }),
        new OptimizeCSSAssetsPlugin({
          cssProcessor: require('cssnano'),
          cssProcessorPluginOptions: {
            preset: [
              'advanced',
              {
                autoprefixer: {
                  add: true,
                  browsers: ['> 1% in DE'],
                },
                discardComments: { removeAll: true },
              },
            ],
          },
        }),
      ],
    },

    plugins: [
      new VueLoaderPlugin(),
      new CleanWebpackPlugin({
        cleanOnceBeforeBuildPatterns: [dist],
      }),
      new ManifestPlugin(),
      new BundleAnalyzerPlugin({
        analyzerMode: 'static',
        reportFilename: path.resolve(
          __dirname,
          `reports/${pkg.version}/treemap.html`
        ),
        openAnalyzer: false,
        logLevel: 'error',
        defaultSizes: 'gzip',
      }),
      new BuildNotifierPlugin({
        title: appName,
        logo: appLogo,
        suppressCompileStart: false,
        sound: true,
      }),
      new MiniCssExtractPlugin({
        filename: isDev ? '[name].css' : '[name].[chunkhash].css',
      }),
    ],

    stats: {
      hash: false,
      version: false,
      timings: false,
      children: false,
      errorDetails: false,
      entrypoints: false,
      performance: isProd,
      chunks: false,
      modules: false,
      reasons: false,
      source: false,
      publicPath: false,
      builtAt: false,
    },

    performance: {
      hints: false,
    },

    module: {
      rules: [
        {
          test: /\.vue$/,
          use: 'vue-loader',
        },
        {
          test: /\.js$/,
          exclude: /node_modules/,
          loader: 'babel-loader',
          options: {
            presets: [['@babel/preset-env', { modules: false }]],
          },
        },
        {
          test: /\.s?(c|a)ss$/,
          use: [
            MiniCssExtractPlugin.loader,
            {
              loader: 'css-loader',
              options: {
                sourceMap: isDev,
                importLoaders: 1,
              },
            },
            {
              loader: 'sass-loader',
              options: {
                sourceMap: isDev,
              },
            },
          ],
        },
        {
          test: /\.(jpe?g|png|gif|svg|webp)$/i,
          use: [
            {
              loader: 'file-loader',
              options: {
                name: isDev ? '[name].[ext]' : '[name].[hash].[ext]',
                outputPath: 'images/',
              },
            },
          ],
        },
        {
          test: /\.(woff(2)?|ttf|eot|svg)(\?v=\d+\.\d+\.\d+)?$/,
          use: [
            {
              loader: 'file-loader',
              options: {
                name: isDev ? '[name].[ext]' : '[name].[hash].[ext]',
                outputPath: 'fonts/',
              },
            },
          ],
        },
      ],
    },
  }
}

/package.json
...
"scripts":
    "dev": "webpack --mode development --progress",
    "prod": "webpack --mode production --hide-modules",
...

/app/helpers.php
<?php

use App\Manifest;

if (!function_exists('manifest')) {
    function manifest($path)
    {
        return app(Manifest::class)(...func_get_args());
    }
}

/app/Manifest.php
<?php

namespace App;

use Exception;
use Illuminate\Support\HtmlString;

class Manifest
{
    public function __invoke($path)
    {
        static $manifestDirectory = '/dist/';

        $manifestPath = public_path($manifestDirectory . 'manifest.json');

        if (!file_exists($manifestPath)) {
            throw new Exception('The manifest file does not exist.');
        }

        $manifest = json_decode(file_get_contents($manifestPath), true);

        if (!isset($manifest[$path])) {
            throw new Exception("Unable to locate file: {$path}");
        }

        return new HtmlString($manifestDirectory . $manifest[$path]);
    }
}

Compiled files should be in /public/dist/. Now replace {{ mix('js/runtime.js') }} with {{ manifest('runtime.js') }}.

A work around for this, is to separate mix.js and mix.css into different files ( so that each file has its own mix instance) :
You can name your files as webpack.css.mix.js and  webpack.js.mix.js
webpack.css.mix.js
mix
.setPublicPath(path.normalize('themes/frontend/assets'))
.sass('themes/frontend/assets/sass/style.scss', 'dist/css')
.sass('themes/frontend/assets/sass/utils/_typografy.scss', 'dist/css') ;

webpack.js.mix.js
mix
.setPublicPath(path.normalize('themes/frontend/assets'))
.js('themes/frontend/assets/js/main.js', 'dist/js/')
.js('plugins/gotorussia/travels/assets/form.js', 'dist/experimental')
.js('themes/frontend/assets/js/map.js', 'dist/js/');

And then you bulid them as follows:
for css: npm run dev --section=css
for js: npm run dev --section=js
Read here  to know how to split and build your files.

I was able to resolve this with a much easier workaround thanks to @escael
There's no need for 2 webpack.mix.js files.
In my project, I was able to modify it as the following:
mix.webpackConfig({
    entry: {
        main: ['./resources/sass/app.scss']
    }
});

I was able to resolve this with a much easier workaround thanks to @escael
There's no need for 2 webpack.mix.js files.
In my project, I was able to modify it as the following:
mix.webpackConfig({
    entry: {
        main: ['./resources/sass/app.scss']
    }
});

Thanks. Worked like magic. Kindly point us to what @escael said so I can understand better what is going on and why it works.

I was able to resolve this with a much easier workaround thanks to @escael
There's no need for 2 webpack.mix.js files.
In my project, I was able to modify it as the following:
mix.webpackConfig({
    entry: {
        main: ['./resources/sass/app.scss']
    }
});

Thanks. Worked like magic. Kindly point us to what @escael said so I can understand better what is going on and why it works.

I think this is the comment @mikesaintsg was referring to.