System error with API v1.18 after starting container

If I run
dockerserver2:~$ docker run -d -p 8190:8186 --name ide container node server.js -p 8186 -l <IP_ADDRESS> -w /root

it works fine.
Same cmd with api
https://<IP_ADDRESS>:2376/containers/create
{"Memory":"100000000","MemorySwap":"0","CpuShares":"1","Cmd":["node server.js -p 8180 -l <IP_ADDRESS>  -w \/root"],"HostConfig":{"PortBindings":{"8180\/tcp":[{"HostPort":""}]},"Dns":["<IP_ADDRESS>"]},"AttachStdin":"false","Image":"container"}

https://<IP_ADDRESS>:2376/containers/1c1152af94635efc9831195568c3e4a79128e292831082633e841973fc7cf389/start

returns
Cannot start container 1c1152af94635efc9831195568c3e4a79128e292831082633e841973fc7cf389: [8] System error: exec: "node server.js -p 8180 -l <IP_ADDRESS> -w /root": stat node server.js -p 8180 -l <IP_ADDRESS> -w /root: no such file or directory

I've updated to 1.6.0

yeah, try to use this with the api (the CMD has to be using the JSON format, the the SHELL format) :
{"Memory":"100000000","MemorySwap":"0","CpuShares":"1","Cmd":["node", "server.js", "-p", "8180", "-l", "<IP_ADDRESS>",  "-w", "\/root"],"HostConfig":{"PortBindings":{"8180\/tcp":[{"HostPort":""}]},"Dns":["<IP_ADDRESS>"]},"AttachStdin":"false","Image":"container"}

It try to find a binary inside the container that would be, litteraly, node server.js -p 8180 -l <IP_ADDRESS>  -w \/root. That's why you get a "no such file or directory".

uhm, will be hard to write complicate commands this way :D
ok, it works.
Thank you so much!


HAWQ-1356. Add waring when user does not have usage privilege of namespace

Currently, in Ranger mode, when a user doesn't have usage privilege on public schema, she cannot see any tables, functions, schemas on public schema. When she login into database and run a query "select * from a"; The error message would be "table a doesn't exist", which makes user confuse.
This fix add a warning to tell user that she does not have the usage privilege of a schema.

+1


Compatibility with Ghost 1.x

Are there any plans to update the theme so that it becomes compatible with Ghost 1.x ?

Thats great ! And thanks for the wonderful theme !


feature request: freeze panes

Feature Request
Thank you for doing this epic rewrite! GJ so far!
I miss freeze_panes from the python version. (I.e. https://github.com/jmcnamara/XlsxWriter/blob/d3050b2d0f6a63415694d186094edbb2ce349279/xlsxwriter/worksheet.py#L3393)
Can't see the feature in your roadmap so I thought I'd add an issue for it.

Thanks for the comments.
I've added Freeze Panes (https://xlsxwriter.readthedocs.io/worksheet.html#worksheet-freeze-panes) to the roadmap and I'll add it to rust_xlsxwriter soon.

Wihoo! Thank you!

I've added this feature to main. See also the app_panes example application.
Try it out and let me know how you get on.

Works great, thank you for this! 😀

This is now available in version v0.10.0: https://rustxlsxwriter.github.io/changelog.html
Best regards.

Woop woop!


Preserve unknown config options when editing app

In #2674 a user raised concerns that a particular configuration option was rest when he used the UI to edit the application config. The UI didn't provide support for the particular option and thus didn't seem to preserve the previous value.
In general, the UI should preserve all configuration that the user did not explicitly change.

In general the UI preserves unknown config parameters.
This problem described with forcePullImage is related to the nested container object and is definitely a specific bug.

@aldipower Do we have tests in place ensuring that we don´t have regressions like #2674? If not I would suppose to add some with this issue.

@mwasn No, we haven't for this specific case. I also think that we should add tests for that.

I have tested this again and cannot reproduce anymore.
I think it is fixed alongside with https://github.com/mesosphere/marathon/issues/2812


Custom command log doesn't exist on new container

and so custom commands on the initial launch are not sent to the client, because the server is not watching the log

closed with https://github.com/flatiron-labs/students-chef-repo/pull/28/commits/624198f1dcc132621e76a49ab23f576d1af334ad


[VTA][Relay] Adding mult coverage to layout tiling in graphpack to compile ResNets

This adds Relay compilation support for ResNet18_v2, ResNet34_v2,  ResNet50_v2, ResNet101_v2, ResNet152_v2 which use broadcast multiplication.
Note: getting quantization to pass on these models is pending on #3543 being merged. I've addressed this dependence with a TODO.

@tmoreau89 maybe we should set limit in tvm init.py

@MarisaKirisame If we set it in init.py, then do we not revert it back to its original value??

@tmoreau89 why revert at all? tvm is supposed to be used with a high recursion limit. if user wish otherwise she should pick a better constant herself.

Ok, which init.py should we include the lines in? the top level?

@tmoreau89 I think relay is fine for now. If tvm also need it, we can move it up lateron.


proposal: Go 2: alternate function call syntax to improve ergonomics of chainable top-level functions

This is a random idea that popped into my head suddenly. I'm not entirely sure that I like it, but I thought that I'd put it out there and see what people think. At the very least, maybe it'll get some more proposals going to try to fix the issue that I'm trying to solve here.
Problem
One of the features purposefully left out of the generics design is adding new type parameters in method declarations. In other words, func (t *SomeType) SomeMethod[T any](v T) is illegal. As the design draft pointed out, the only real functionality difference between methods and top-level functions in Go is in interface satisfaction, and how methods that can add new type parameters would affect satisfaction has a lot of subtle implications. One solution that has been proposed is that those methods simply shouldn't count at all towards interface satisfaction, but then the question is why bother making them methods at all.
Unfortunately, top-level functions are not always ideal. While it's true that there's no functionality difference outside of interface satisfaction, certain common systems, such as iterators, lend themselves towards APIs that are very awkward as top-level functions. Under the current generics proposal, iterator transformation functions, such as map and filter, would have to be implemented as top-level functions, but top-level functions for iterator chaining can be very messy.
One option is to call those functions one after another with large numbers of intermediary variables:
// It's a bit of a contrived example, I know.
it := iter.OfSlice(s)
trunc := iter.Map(it, func(v float64) int { return int(v) })
trunc = iter.Filter(it, func(v int) bool { return v > 0 })
strings := iter.Map(it, func(v int) string { return fmt.Sprintf("%x", v) })
return iter.Slice(it)

This is very messy, as well as error prone. Some variable have to be new because they have new types, but some can be the same, and naming all of them something useful is a whole extra thing to worry about pointlessly. An alternative is to nest the calls, but that's actually worse:
// The reads like a C function pointer type declaration: Inside-out.
return iter.Slice(
  iter.Map(
    iter.Filter(
      iter.Map(
        iter.OfSlice(s),
        func(v float64) int { return int(v) },
      ),
      func(v int) bool { return v > 0 },
    ),
    func(v int) string { return fmt.Sprintf("%x", v) },
  ),
)

Proposal
The idea is simple: Add a syntax, probably in the form of a new operator, that allows top-level functions to be chained like methods. It would be nothing but syntax sugar.
An example syntax for this might look like a() -> b(). This would be equivalent to b(a()). With this syntax, the result of the expression on the left is passed as the first argument of the function call on the right. All other arguments are handled normally. In other words, b(a(1, 2, 3), 8, 9) could also be written as a(1, 2, 3) -> b(8, 9). This usage would make the syntax compatible with method expressions, as well as the majority of functions that already exist due to standard argument order conventions, and allow functions written with this syntax in mind to follow a standard argument ordering as well.
Using this syntax, the above admittedly-contrived iterator example could be rewritten as follows:
return iter.OfSlice(s) ->
  iter.Map(func(v float64) int { return int(v) }) ->
  iter.Filter(func(v int) bool { return v > 0 }) ->
  iter.Map(func(v int) string { return fmt.Sprintf("%x", v) }) ->
  iter.Slice()

It should be noted that this would only be legal if the expression on the left side has at most one return. A multi-return version could be implemented, but this proposal is only for a single-return-only variant.
Conclusion
Like I said above, I'm not entirely sure about this idea myself. One particular problem that I have with it is the namespacing required when chaining to an imported function, but I thought that I'd at least propose it as the lack of additional type parameters on methods is my biggest issue with generics as currently proposed, and this could solve that by simply sidestepping the issue completely.
Another potential issue that I have with this is that if it is decided later to try to allow methods with new type parameters that do satisfy interfaces, this will probably feel fairly redundant, but it could still be useful as pseudo extension functions.
Feel free to leave a thumbs-down if you think that it's too weird.
Language Change Template
Would you consider yourself a novice, intermediate, or experienced Go programmer?
Experienced.
What other languages do you have experience with?
C, Ruby, Python, Kotlin, Java, Rust, JavaScript, and a few others.
Would this change make Go easier or harder to learn, and why?
Slightly harder due to there being an extra syntactic detail to learn, I suppose, but the idea's pretty straightforwards.
Has this idea, or one like it, been proposed before?
I don't think so.
Who does this proposal help, and why?
Anyone trying to write a complicated API that lends itself to chained function calls but that has to be written as top-level functions, It also allows for what are essentially extension methods by way of making top-level functions behave like methods, allowing, for example, for a third-party package to implement some new middleware iterator function and for it to integrate well into existing systems.
What is the proposed change?
Add a new syntax sugar that allows the first argument to any regular, top-level function to be specified before the name of the function. One possibility is that of an -> operator that does just that, making b(a(1, 2, 3), 8, 9) completely equivalent to a(1, 2, 3) -> b(8, 9).
Is this change backward compatible?
Yes.
Show example code before and after the change.
See above.
What is the cost of this proposal? (Every language change has a cost).

How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?

A few would definitely, especially the formatters.

What is the compile time cost?

There would be one extra syntactical structure that needs to be parsed, so there would be one, but it would probably be pretty minor.

What is the run time cost?

Non-existent.

Can you describe a possible implementation?
Nope.
Do you have a prototype? (This is not required.)
Nope.
How would the language spec change?
It would need a new section under function call syntax that would describe this syntactical feature.
Orthogonality: how does this change interact or overlap with existing features?
It complements function call syntax by allowing for certain patterns that are currently unfeasible due to incredibly awkward ergonomics.
Is the goal of this change a performance improvement?
No.
Does this affect error handling?
As currently proposed, no, not really, but a variant could allow for chaining functions with multiple returns and then it could be useful.
Is this about generics?
It was inspired by an issue that came up in the generics design, but it doesn't have anything to do with generics directly itself.

related - https://github.com/golang/go/issues/33361
Personally, i think that this problem is better remedied by allowing to shadow variables within the same scope, similar to Rust. This is another way which allows for removing temporary variables, while keeping argument-passing explicit:
it := iter.OfSlice(s)
it := iter.Map(it, func(v float64) int { return int(v) })
it := iter.Filter(it, func(v int) bool { return v > 0 })
it := iter.Map(it, func(v int) string { return fmt.Sprintf("%x", v) })
return iter.Slice(it)

I know Go wanted to go the route of "we should remove all variable shadowing", and obviously this is a step in the opposite direction. But I think that it may provide a very significant benefit whenever we have iterators/streams/etc.
The one thing I'm afraid of is of people starting to use := everywhere.

I know Go wanted to go the route of "we should remove all variable shadowing", and obviously this is a step in the opposite direction.

I think that the shadowing problem actually stems more from the oddity of := combined with multiple returns, not that it exists at all. I think that Go needs to move towards variable declaration being per-variable on the left-hand side of the assignment, not an all-or-nothing like := is.

@deanveloper I recently found a serious bug in my work software and it was due to shadowing. So, please, let'd not go there.

This syntax doesn't seem to support error handling very well.
It also does not have strong support based on emoji voting.
Therefore, this is a likely decline.  Leaving open for four weeks for final comments.


feat: auth-redux

Describe
Added the auth and login state update
Issue
resolves #26

A general advice, you don’t close and open a new PR each time you have to make a change. You can either push more commits to the same branch or amend the previous commit. Helps us to manage things better :)

Oh sorry my bad! Will not be repeated

@dvjsharma Any changes needed ?

@dvjsharma any updates?

https://github.com/dvjsharma/Drawn2Shoe/assets/101277141/b6492fb9-5839-4f37-b9b8-5e335a18f29f
I have added the logout feature also and stored the login info on redux

Hey @Sid-80, good work on the redux part. But from the last review I still cannot see the changes I asked. Please do the following:

Revert any indentation change which is not relevant for this PR.
Rebase with master branch.
Revert any changes made in config files. They are specific for your system and should not be tracked globally.

https://github.com/dvjsharma/Drawn2Shoe/assets/101277141/da56c6f1-832d-4ef2-a1f8-2cc02deb7d2a
@dvjsharma Hey! I have made all the requested changes. Please review it.
I have redux-persist for keep the redux-store persistent unless the user's logout.

@dvjsharma Please review it!

Hey @Sid-80. Continuously pinging us would not guarantee speedy review but will surely guarantee that we are annoyed. Please respect the general waiting period in open source, that is 1 week
CC @ShashankShekhar07

Hello @Sid-80. I still do not see the requested changes implemented. Please do the needful so we can complete the merge.

I made all the changes to server config.

@dvjsharma Please review once! Reverted the changes made in server.


readOnly / writeOnly support for OpenAPI 3.1

Seems like read/write context-aware validators are only implemented for OpenAPI 3.0. Any reason not to implement a similar interface for 3.1?
For some context, I'm leveraging the openapi-core library and noticing that readOnly and writeOnly work great when validating against 3.0 specs, but do nothing with 3.1 specs.

The answer is very simple, because OpenAPI 3.1 specification doesn't define readonly/writeonly.
the reason can be found here

When discussing the final details of aligning with JSON Schema, we identified there was particularly thorny issues with the readOnly and writeOnly properties that are defined in JSON Schema but described to have slightly different behavior in OpenAPI. In order to achieve our goal of full alignment with JSON Schema, we had to drop the OpenAPI behavior. Technically, this change might “break” some piece of tooling out there. We haven’t found it yet (we’re still looking). Semantic versioning would insist that this change be denoted as 4.0.0. However, this update to the specification is not such a major update, rather there are a few small breaking changes.

https://www.openapis.org/blog/2020/06/18/openapi-3-1-0-rc0-its-here


Suggestions to expressly limit rights

@theseawitch I think we had a discussion about this months ago with @vjayn and others, or perhaps it was another Github lawyer? Regardless I finally submitted the suggestions. @acrlewis @jsrigby

The goal was not to clarify that no additional grants were required, rather that none are given, i.e. Github gets the rights described in the TOS + rights based on the license. Users get the rights to use it in Github + rights based on the license.

On Fri, Oct 06, 2017 at 02:07:23PM -0700, craigez wrote:

The goal was not to clarify that no additional grants were required,
rather that none are given, i.e. Github gets the rights described in
the TOS + rights based on the license. Users get the rights to use
it in Github + rights based on the license.

I'm confused.  You're concerned that the ToS would be a vehicle for
granting GitHub and/or other users more rights than the ToS requires
you to grant them?  Assuming there is a agreement on the set of rights
covered by “You grant us…”, “you grant each user…”, etc., I don't
see how the ToS could be construed to grant additional rights.
Towards the end of the ToS, there's [1,2]:
These Terms of Service, together with the GitHub Privacy Statement,
represent the complete and exclusive statement of the agreement
between you and us.
The project license isn't listed in that line, but maybe it gets
looped in due to references from the ToS like the existing [3,4]:
If you upload Content that already comes with a license granting
GitHub the permissions we need to run our Service, no additional
license is required.
but however the project license is included in that complete-agreement
clause, it seems to me that the purpose of the complete-agreement
section is to make clear that nobody is granting anybody rights that
aren't discussed in the ToS or documents referenced from the ToS.

The goal was to strength the ToS in this regard. It's just incremental improvements to something that is already fairly good. One suggestion in the PR is to move away from giving specific examples of things that are not included:

the right to sell Your Content or otherwise distribute or use it outside of our provision of the Service

as it could potentially be construed that some right not explicitly listed as excluded may be granted.

On Fri, Oct 06, 2017 at 10:16:13PM +0000, craigez wrote:

One suggestion in the PR is to move away from giving specific
examples of things that are not included:

the right to sell Your Content or otherwise distribute or use it
outside of our provision of the Service

as it could potentially be construed that some right not explicitly
listed as excluded may be granted.

That makes sense to me.  And if “this license” is provided via the
project license, it may include the right for GitHub to sell Your
Content (e.g. the OSI's free-redistribution criterion forbids
restricting the right to sell the licensed software 1, so GitHub is
free to sell any OSI-licensed software).  I am in favor of removing
that specific example.
But I don't see the need (yet?) for a blanket “but not other rights”
clarification to replace-ish the former specific example.

Thank you all for your comments! Closing this pull request, since we have not incorporated these changes at this time.


Add documentation for middleware in general, plus CORS and GZip.

Relates to documentation meta-ticket #679 and the hugo reboot issue #782.
I set the Hugo weight to values that put the new documentation into what I thought were reasonable places in the navigation. The inter-documentation links are also relative to the new Hugo directory/file structure. So, if we don't go with Hugo, those will need to be re-jiggered.

When this is ready, either you or I can rebase onto #802.  These need to go in src/main/tut now.

Cherry-picked onto #802.  Thanks!


Add snap support

This PR adds a working confined snap.
For now it needs to be connected to the kde content snap, but a request for autoconnection can be opened on the snapcraft forum.

The appindicator icon issue is not fixed yet! it might need also another override..
I'll test and upload the new fix

It works if XDG_CURRENT_DESKTOP is set to Unity7

I just gave this a try and it seems to have similar issues as my snap:

It deals badly with hi-dpi scaling (many widgets appear at half the actual size).
The system tray icon still does not show.
There is an issue with the terminal encoding and the CLI. But that is easily fixed by setting the environment variables LC_ALL=C.UTF-8 and LANG=C.UTF-8.
Qt throws lots of errors about not being able to send dbus messages. But this should probably be expected...

Here is the screenshot of the setup window from the snap:

And here is how it should look, installed with pip:

I really don't understand the choices behind snap sandboxing. MacOS has had sandboxing for quite some time now but this does not prevent the apps form getting read access to standard system resources or write access to its own config and resource folders (e.g., in ~/.config/appname)

There should be a fix for the theming (and hi-dpi)..
The indicator is shown on my computer.. I'll try in a clean vm..

Does it work if you run QT_AUTO_SCREEN_SCALE_FACTOR=0 maestral.maestral-qt
If it does it can be added to the environment in the snapcraft.yaml
I think the proper value is 0, but it might be 1... I cannot remember

Snaps have access to their own config/resource folder, but it's relocated to ~/.snap/maestral/current/.config/maestral, so it's isolated from the rest of the system.
Every snap has it's own fake home folder for config/tmp files/...
I'm not a snap architect, so I cannot speak for the merits of the system, just that this is how it works.

The indicator should work now if you were previously running maestral gui

Snaps have access to their own config/resource folder

Yes, that is their design choice. A bit confusing to users but fair enough.

Does it work if you run QT_AUTO_SCREEN_SCALE_FACTOR=0 maestral.maestral-qt

It does not work unfortunately. Qt should automatically detect high-dpi scaling and adjust accordingly if the AA_EnableHighDpiScaling flag it set (which it is). As far as I understand, this flag can be set by the user with QT_AUTO_SCREEN_SCALE_FACTOR=1 if the application already does not do so itself.

I have also tried the new snap. The tray icon still not show, for either the desktop entry or the maestral gui command. Not sure why. I know that Qt tries to use D-Bus StatusNotifier when possible but I am not sure what the fallback option is.
I am running it on a clean Ubuntu 19.10 VM.

Another issue I have noticed: there is a memory leak trying to show the tray icon. I noticed when debugging the issue inside the snap's shell (snap run --shell maestral). Memory usage increases by the tray icon size every second when Qt tries and fails to set the icon.

Strange..
Does the memory leak happen also with the TMPDIR option added back to envorinment in the snap yaml?

I'll give it a try.

I'm afraid it is still leaking memory and the icon does not show either.

Did you connect the snap to the kde content snap?
snap connect maestral:kde-frameworks-5-plug kde-frameworks-5-core18:kde-frameworks-5-core18-slot

Of course.

Some progress on the high-dpi scaling: it works when manually setting the environment variable QT_SCREEN_SCALE_FACTORS to a list of appropriate scale factors for each screen. The problem seems to be that Qt cannot get the scaling which the user sets in "Settings > Devices Screen Display". Possibly another one of those sandboxing decisions? This does not seem to be issue with snaps that use Gtk.
Regarding the appindicator / sys tray icon, I am lost. I know that Qt tries to set it via Dbus, but the Unity7 plug should give it permissions to do so, right?

I had that same issue with other qt applications (not snaps) so I assume it's a qt issue.
Unity7 gives the permission to use the appindicator. If you remove that plug it should show the older systray icon. I tried removing completely and rebuilding and I can successfully see the appindicator.

I had that same issue with other qt applications (not snaps) so I assume it's a qt issue.

It should not be an issue with qt as long as the app enables AA_EnableHighDpiScaling, which some qt apps forget to do if the developers don't routinely use Linux on high-dpi screens. macOS completely abstracts high-dpi scaling so there is no need to bother.

I tried removing completely and rebuilding and I can successfully see the appindicator.

That does not seem to work for me either :/ This must be either some difference in packaging the snap (which I am doing on macOS) or with the Ubuntu VM which I am using.

Ok, so I tested the snap I built on an ubuntu (gnome) vm and it fails to show the indicator.
In an ubuntu-mate vm it works perfectly.
I'll try and ask on the snapcraft forum, but it seems to be an issue with the connection between snapd and the indicator extension in gnome.

Lets see if we get a helpful response from the community. As far as I can see from the Unity7 interface specification here, all necessary permissions are given. Sending desktop notifications via Dbus for instance works perfectly well.

with this option set under environment it works in the clean ubuntu gnome vm:
QT_QPA_PLATFORMTHEME: gtk3
I'm trying now to rebuild without the other ones..

Unfortunately it still does not work for me 😟 Monitoring the dbus activity, I can see that Qt send both the icon path /run/user/1000/snap.maestral/qt-trayicon-BDHjwk.png (is this the correct runtime dir for the snap?) as well as the raw pixmap data. Setting QT_QPA_PLATFORMTHEME=gtk3 does not make a difference in that communication.
dbus-monitor output

method return time=1585582358.458033 sender=:1.309 -> destination=:1.38 serial=33 reply_serial=18877
   array [
      dict entry(
         string "AttentionIconName"
         variant             string ""
      )
      dict entry(
         string "AttentionIconPixmap"
         variant             array [
               struct {
                  int32 0
                  int32 0
                  array [
                  ]
               }
               struct {
                  int32 0
                  int32 0
                  array [
                  ]
               }
            ]
      )
      dict entry(
         string "AttentionMovieName"
         variant             string ""
      )
      dict entry(
         string "Category"
         variant             string "ApplicationStatus"
      )
      dict entry(
         string "IconName"
         variant             string "/run/user/1000/snap.maestral/qt-trayicon-BDHjwk.png"
      )
      dict entry(
         string "IconPixmap"
         variant             array [
               struct {
                  int32 22
                  int32 22
                  array of bytes [
                    ...
                  ]
               }
               struct {
                  int32 64
                  int32 64
                  array of bytes [
                    ...
                  ]
               }
            ]
      )
      dict entry(
         string "Id"
         variant             string "Maestral"
      )
      dict entry(
         string "ItemIsMenu"
         variant             boolean false
      )
      dict entry(
         string "Menu"
         variant             object path "/MenuBar"
      )
      dict entry(
         string "OverlayIconName"
         variant             string ""
      )
      dict entry(
         string "OverlayIconPixmap"
         variant             array [
            ]
      )
      dict entry(
         string "Status"
         variant             string "Active"
      )
      dict entry(
         string "Title"
         variant             string "Maestral"
      )
      dict entry(
         string "ToolTip"
         variant             struct {
               string ""
               array [
               ]
               string "Not linked."
               string ""
            }
      )
   ]

Strange.. I tried installing in a clean ubuntu vm ..
The only other thing installed is the kde framework snap, so it can be connected.
Did you pass the setting or try installing the snap (I added the env variable in the yaml).
It might be needed to have the variable declared in the snap instead of added at runtime

Never mind, it does work! Environment variable magic :) However, the icon is black instead of white so I didn't see it on the non-opaque menu bar in Ubuntu 19.10 ...
Now for the wrong icon colour, Maestral determines the correct icon as follows:

If it runs on Gnome 3, it attempts to locate the "symbolic" icons which are installed in the hicolor theme. Those are correctly installed in the snap at /snap/maestral/x2/share/icons. Those icons will adopt their colour automatically but are only supported in Gnome 3 (KDE uses another spec for symbolic icons which Maestral does not support at the moment). However, Maestral reads the Gnome version from /usr/share/gnome/gnome-version.xml, which fails from within the snap. Therefore, it uses its fallback mechanism.

As a fallback, it tries to infer the location of status bar and determine its colour by reading pixels  from the screen. It then selects a contrasting icon colour. This also fails from within the snap.

Maestral gives up and reverts to black PNG icons.

To support snaps on multiple platforms, one would ideally get both step 1 and step 2 right. Detecting Gnome 3 should be possible from within the snap and will likely involve some change to maestral itself. Step 2 might need another plug?

should be possible by adding another plug for system file read access (https://snapcraft.io/docs/system-files-interface), but it wouldn't be auto-connected, so it be better to inquire whether it would be connected after a request.
would might not work in the snap at all..

As a sidenote.. is anything using gnome2 atm? xfce and mate are both (mosty) gtk3..
Should the check be on XDG_SESSION_DESKTOP (so you could determine whether KDE is in use?

Yes, I am using Gnome2! We have a number of PCs in our lab that still run CentOS 6 to support legacy software.
XDG_SESSION_DESKTOP is checked, that is exactly how I determine if KDE is used. I just haven't gotten around to creating SVG icons that follow their symbolic spec.

There are some snaps for screenshots such as https://github.com/flameshotapp. I'll have a look at their plugs. Its unlikely an autoconnect is granted just to determine the status bar colour.

Ah ok!
Couldn't XDG_SESSION_DESKTOP be used to identify a gnome2 DE?

I stand corrected, I am not using XDG_SESSION_DESKTOP but only XDG_CURRENT_DESKTOP and GDMSESSION at the moment.

Ah.. in the snap we set XDG_CURRENT_DESKTOP to Unity.
It might be possible to set it in the snapcraft.yaml to
XDG_CURRENT_DESKTOP: Unity:$XDG_CURRENT_DESKTOP
to see it it retains the part you're using..

Yeah, I noticed that. But is setting XDG_CURRENT_DESKTOP really necessary? It works absolutely fine with QT_QPA_PLATFORMTHEME: gtk3 for me.

Did you test it already without that variable set?
I'll try and rebuild/run with just QT_QPA_PLATFORMTHEME and test on ubuntu and ubuntu-mate.
If it's not needed better!

I tried, and I cannot see the icon if XDG_CURRENT_DESKTOP is not set to unity...
I can set it like this to show also the "real" desktop:
XDG_CURRENT_DESKTOP: "Unity:$XDG_CURRENT_DESKTOP"

Ok, XDG_CURRENT_DESKTOP: "Unity:$XDG_CURRENT_DESKTOP" should work as well.
A few issues which I noticed when trying out the snap:

The snap defaults to selecting x3 or a similar directory instead ~/snap for the Dropbox folder. This is an unexpected user experience. However, changing HOME may have some adverse effects on where config files are stored unless XDG_CONFIG_HOME it set. Luckily, it looks like the desktop launcher sets XDG_CONFIG_HOME correctly, despite it being not set in Ubuntu by default.

File / folder chooser dialogs appear to be run by another process. This makes sense for sandboxing but the implementation here causes several issues:

The chooser appears underneath the respective window which launched it (settings pane, setup dialog). This appears to be issue with the Maestral windows set to always stay on top combined with the chooser running in a different process. Keeping the settings window etc on top is only really necessary for macOS where a system tray app does not get a dock entry and windows can get "lost". This can be changed for Linux.
Configurations such as choosing / displaying only folders are not respected.

A cosmetic detail: system themes are not applied for icons etc.

I still struggle to automatically enable high-dpi scaling and have noticed that other Qt snaps don't get this right either (eg. https://redisdesktop.com) even through the natively packaged versions work well.

System themes should work, but for themes contained in the snap gtk-common-themes
I've had issues myself with the folder chooser.. that might be an issue/bug to report on the forum.
The snap has full access to it's "fake" home folder, so that it can be used for the configurations without escaping the confinement. In maestral (or via an env variable) it could be possible to set the folder dialog to default to the "real" home
Unfortunately I cannot properly test the high-dpi part, but I did see some fixes a while back in the snapcraft forum.

System themes should work, but for themes contained in the snap gtk-common-themes

Strange. Maybe Ubuntu's Yaru theme is not yet included in gtk-common-themes.

The snap has full access to it's "fake" home folder, so that it can be used for the configurations without escaping the confinement. In maestral (or via an env variable) it could be possible to set the folder dialog to default to the "real" home

This is not really a folder dialog issue but rather a problem with Maestral defaulting to the "wrong" folder without the user selecting one. But is should be fixable with environment variables.
I can look into the high-dpi issue. It probably is related to Qt looking at the wrong settings.

Yaru is for sure in the gtk-common-themes..
Could be that this package is missing in the stage-snaps part:
qt5-gtk-platformtheme
I'll try and rebuild and let you know

No.. I tried a few different packages that were suggested in the forum and it doesn't work.
It's strange, because the snap is connected to the gtk-common-themes content snap, and that is used for themes, cursors, icons.

Progress on some fronts:

Setting HOME to /home/$USER works on most systems (with standard home directory locations) to give sane defaults. The alternative would be to set HOME in a wrapper launch script which uses more robust checks than $USER. A discussion of possible options is given here. This has also revealed a bug in Maestral: the data dir was accidentally set to XDG_DATA_DIR instead of XDG_DATA_HOME. The former won't be set in our snap environment.

The open file dialogs: Qt uses xdg-desktop-portal when it detects that it is running in a snap. Initially developed for flatpak, this dbus interface supports choosing files vs directories. However, it seems like this is only properly support in Qt 5.12 and higher while the snap currently uses version 5.9.5. Would it be possible to use a newer version of Qt? I also suspect that this would improve high-dpi support...

While we are updating versions: Is there any benefit in using Python 3.6? Python 3.8 may provide significant performance improvements for copying and removing file trees, depending on the platform and file system. Both are frequent use cases in downloads and conflict handling.

Just a note to myself, for future reference: The autostart functionality will need testing.

GUI: Maestral has checkbox to start the GUI on login and does so by creating a .desktop entry at ~/.config/autostart with the appropriate launch command. This approach seems to be currently not supported by snaps, even through there is some discussion on the forum.

Daemon: Maestral creates autostart entries by calling systemctl --user enable on a .service file which is generated at runtime to launch the correct config and executable. I am not sure if this is or will be possible from a snap.

The relevant module is maestral.utils.autostart and template files are in maestral/resources.

I'm testing the snap with an autostart option, as described here: https://snapcraft.io/docs/snap-format.
I added autostart: maestral-maestral.desktop under apps: maestral-qt:
but it doesn't seem to work.
Regarding the daemon: that is feasible with https://snapcraft.io/docs/service-management
by tagging in the yaml the daemon.
I've never tried this approach but it should work

The autostart .desktop file has the incorrect Exec line:
it point so /snap/maestral/x14/bin/maestral gui -c 'maestral'
instead of either maestral gui -c 'maestral'
or /snap/bin/maestral gui -c 'maestral'

I removed the extra maestral-qt command.
Now the snap functions like the normal version (calling maestral gui will start the ui)
I tried changing the autostart .desktop file to the spec, but it doesn't start on boot.

The autostart .desktop file has the incorrect Exec line

It seems like which maestral returns /snap/maestral/x4/bin/maestral from inside the snap, which of course only works from within the snap. The reason to use an absolute path in the first place is to prevent issues when maestral is installed for the user only and its executable may not be in PATH. But I am not sure if this is really necessary.
Regarding the daemon, that does seem feasible. I will have to look into the details of having different services for different config names. This is currently done through systemd's service "templates" with the<EMAIL_ADDRESS>syntax so that any number of services can coexist to sync multiple accounts.
In any case, a snap seems to control its own services with snapctl. It may therefore be necessary to include explicit snap awareness in the autostart module.

Regarding newer versions of Qt and Python, the easiest way may be to just switch to the core20 base.

At the moment core20 is not fully developed.. especially the kde content interface.
But if you want to update the qt version we could link to kde-frameworks-5-qt-5-14-core18 instead of kde-frameworks-5-qt-core18
I'll try it now

Yes, I agree. For now, the snap is in good shape and I expect that the remaining issues with folder selection dialogs will be fixed with a qt upgrade in core20. The high-dpi scaling issue certainly lies with Qt 5.9 and not with the snap environment, I can reproduce it outside of the snap.
Same goes for kde-neon: if I understand the forum posts correctly, the reviewers are reluctant to grant individual autoconnect requests for kde-frameworks-5-qt-core18 and would prefer a global autoconnect.
I think the easiest way right now really is to wait for core20 and kde-frameworks-5-qt-core20, both may even come some time this month.
I am going to merge this and aim for snap support in the autostart module by the time core20 comes out. Thank you for all the work you have put into this!

PS: I have learned a lot about snaps and their unique approach to sandboxing!

I guess the Qt 5.9 requirement really is a minimum requirement. It won't crash, but it won't look good on several platforms systems either.


Executing the awscli throws NullPointerException on subsequent calls after login

When executing the awscli with the following properties:
OKTA_ORG=[okta tenant]
OKTA_AWS_APP_URL=[application url]
OKTA_USERNAME=
OKTA_PASSWORD=
OKTA_AWS_ROLE_TO_ASSUME=
I am prompted to authenticate as expected.  When I execute the awscli a second time I get the following Exception:
Exception in thread "main" java.lang.NullPointerException
at com.okta.tools.OktaAwsCliAssumeRole.run(OktaAwsCliAssumeRole.java:109
)
at com.okta.tools.awscli.main(awscli.java:31)
At this point.  From the code there is a check for oktaProfile.isEmpty()
if (session.isPresent() && sessionIsActive(startInstant, session.get()) && oktaProfile.isEmpty())
Since this property is not defined a NullPointerException is thrown.  When I add the property to the config.properties.  The exception goes away and everything works as expected.  Except for logout.
Logout throws the following exception:
Exception in thread "main" java.lang.NullPointerException
at org.ini4j.BasicProfile.remove(BasicProfile.java:139)
at com.okta.tools.aws.settings.MultipleProfile.deleteProfile(MultipleProfile.java:47)
at com.okta.tools.OktaAwsCliAssumeRole.logoutMulti(OktaAwsCliAssumeRole.java:158)
at com.okta.tools.OktaAwsCliAssumeRole.logoutSession(OktaAwsCliAssumeRole.java:144)
at com.okta.tools.awscli.main(awscli.java:25)
If I remove the property from the config then logout works, so I am in a catch 22 scenario.

@joewitt99 Thank you for submitting this issue on GitHub as well. As per our internal discussion, we will take a look at this as soon as possible.
CC @AlainODea @smashling @mraible - Issue opened following an internal ticket opened with support by Joe who's an Okta employee.

I believe this issue was fixed  in Pull request #96 :bug: NPE on second run with no profile name unless I am misunderstanding the error.

I pulled the master and built the snapshot and I was able to get past the errors..   Thanks, which will there be a 1.0.1 GA release?

I can do one today. It’s automated, so I just need to create a release/tag on GitHub and it auto-publishes with Travis.

On Mar 16, 2018, at 11:56, joewitt99<EMAIL_ADDRESS>wrote:
I pulled the master and built the snapshot and I was able to get past the errors.. Thanks, which will there be a 1.0.1 GA release?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Thank you @mraible 😄

@mraible looks like the okta-aws-cli-1.0.1.jar didn't get uploaded to the releases page

I'll upload it now. The automation doesn't add it to the release - that's a manual process. It does auto-upload it to https://packagecloud.io/oktadev/okta-aws-cli-assume-role. Maybe we should add that URL to the README?

Thanks for the link. I think adding that URL to the README is a good idea.


Condition for VisibleIf

Hi, i have a question... my survey's page is something like this:

question1 (one checkbox with value "S" if it's checked)
question2 (with visibleIf condition like "{question1} <> 'S'")

When the survey start, the second question will be visible, but is hidden, when i put the flag on question1 and then i remove this flag, the second question be shown
Why when the survey start, the condition not work?
Thanks :)

@care46 Yes, we do not support <> yet. It makes sense to add it as well.
Please use !=, "{question1} != 'S'"
Thank you,
Andrew

I have already try with !=, but it's the same.... i try with the online editor...
Maybe i miss something?

@care46 I just found a bug. It doesn't work when the {question1} is not setup. It will return false. I am working on the fix.

Thanks! ;)

@care46 and in fact support for '<>' is already there. Sorry about misleading.
The fix will be in the next minor update, likely on this week.
Thank you,
Andrew

Fantastic! ;)
Thanks!

@care46 Could you please check, if everything is fine with the new version?
Thank you,
Andrew

@andrewtelnov it's OK!!!!


Pront PDF file

How to Print PDF file ?

Hi!
This is a general purpose BLE central library. Consult manufacturer's documentation for your peripheral.


Infinite loading at Central Shroud

Since 7.0, when I go to Central Shroud, it doesn't progress to infinite loading. I'm using Japanese -> Korean modding.

Same issue at English > Korean modding.

Same here.
enable modding cause endless loading


Download all images on the page

/download-images command in the search bar runs the following plugin script
const run = async () => {
  const dirHandle = await window.showDirectoryPicker();
  const imgs = document.querySelectorAll("img");
  let i = 0;

  imgs.forEach(async (img) => {
    const url = img.src;
    const name = `img-${i}.png`;
    i++;

    try {
      console.log(`Fetching ${url}`);
      const response = await fetch(url);

      console.log(`Saving to ${name}`);

      const file = await dirHandle.getFileHandle(name, { create: true });
      const writable = await file.createWritable();
      await response.body.pipeTo(writable);
    } catch (err) {
      console.log(err);
    }
  });
};

run();

https://paul.kinlan.me/bookmarklet-to-download-all-images-on-a-page-with-the-file-system-api/

@aashu0148 here's another one that needs finished if you're lookin for another plugin to hack on!? the #481 has the work started but needs a few tweaks before it's ready. 🙂

@aashu0148 here's another one that needs finished if you're lookin for another plugin to hack on!? the #481 has the work started but needs a few tweaks before it's ready. 🙂

I'll check for sure.
But now i have a function in my family 🥳🥳
I'll check later

@argyleink I'll be happy to work on this issue but can you please tell me where the javascript file is located from which i can access the value entered in the search box.

sure!
PR #481
branch download-images-plugin
file with function invoked by slash command https://github.com/GoogleChromeLabs/ProjectVisBug/pull/481/files#diff-594f34f26bc63ff8ca673fe36c1acded478fe92a04306aa9783f8ab50fe4d3e8

Hey @argyleink  I'm really sorry for this delay but first i was busy in my family functions and then i got my exams but i thought i can easily make a good percentage in my exams but after giving my first exam i realized that this will not going until i dedicatedly study for it... so I decided to study for my exams and forgot about informing you..... yesterday was my last exam. I'll be working on this issue from now itself.
Again So sorry for accepting this issue and not active for such a long period :(

hey @argyleink I run it on my machine and it is downloading all the images.
What's for me in it ?

yes, sorry, I see I never listed the missing aspects of the feature!
Currently, the user picks a folder to save the images to, and all the images download, but there's many that are broken and the original names of the images is lost. A file named logo.svg should save as logo.svg, where right now it saves as img-2.png. Both the name and src type are not brought along in the download.

[ ] file should save as the same name the src file is https://a.io/images/foo.svg -> foo.svg
[ ] file should save as it's natural src type
[ ] remove console logs
[ ] should feature check for showDirectoryPicker support and alert if not available
[ ] test on various websites

Thanks for the help!

also, would be cool if it downloaded all images that were referenced via CSS too! background images, etc. want to investigate level of effort to adding that too?

okay @argyleink we will move to CSS images also later on but now let me work on javascript to complete the above mentioned tasks :)

/

hey @argyleink  first task is completed i think. If not please let me know;

hey @argyleink to check for showDirectoryPicker can we put it into try and add a alert in catch.
Will this work ?Because i dont know how to test this as my machine support showDirectoryPicker

nice work on the names and file extensions 👍🏻
you could try catch for feature testing yeah. i just tested this and it works too:
if (window.showDirectoryPicker === undefined)
  console.log('no directory support')

here's some JS that grabs the external urls from stylesheets on the page:
let css_urls = [...document.styleSheets]
  .filter(sheet => {
    try { return sheet.cssRules }
    catch {}
  })
  .flatMap(sheet => Array.from(sheet.cssRules))
  .filter(rule => rule.style)
  .filter(rule => rule.style.backgroundImage !== '')
  .filter(rule => rule.style.backgroundImage !== 'initial')
  .filter(rule => rule.style.backgroundImage.includes("url"))
  .reduce((urls, {style}) => {
    urls.push(style.backgroundImage);
    return urls;
  }, []);

console.log(css_urls);

output example:
["url("../media/foo.jpg")", "url("../media/bar.svg")", "url("../media/baz.png")"]

seems doable with this concept proof yeah!?

here's some JS that grabs the external urls from stylesheets on the page:
let css_urls = [...document.styleSheets]
  .filter(sheet => {
    try { return sheet.cssRules }
    catch {}
  })
  .flatMap(sheet => Array.from(sheet.cssRules))
  .filter(rule => rule.style)
  .filter(rule => rule.style.backgroundImage !== '')
  .filter(rule => rule.style.backgroundImage !== 'initial')
  .filter(rule => rule.style.backgroundImage.includes("url"))
  .reduce((urls, {style}) => {
    urls.push(style.backgroundImage);
    return urls;
  }, []);

console.log(css_urls);

output example:
["url("../media/foo.jpg")", "url("../media/bar.svg")", "url("../media/baz.png")"]

seems doable with this concept proof yeah!?

ya it seems you already done most of my work.
Thanks :)
I'll update you soon

hey @argyleink  I'm stuck with an awkward issue :/
can't say why is this showing. The issue is that i have changed the JS file and in the console it is still showing the console logs and not implementing my changes. I have closed vs code 3-4 times and re run the localhost dozen of times but still it is not showing the console according to the current code.
I'm attaching the screenshot of that please help me with that. check there in the console it says at line no 48,53,54 but in my code there is no console logs on that lines.. there are some before but i had deleted them but it is not showing the updated result.
can you please take a look at it. I'll also continue to find the problem and update you if it is solved.

hey @argyleink I'm stuck with an awkward issue :/
can't say why is this showing. The issue is that i have changed the JS file and in the console it is still showing the console logs and not implementing my changes. I have closed vs code 3-4 times and re run the localhost dozen of times but still it is not showing the console according to the current code.
I'm attaching the screenshot of that please help me with that. check there in the console it says at line no 48,53,54 but in my code there is no console logs on that lines.. there are some before but i had deleted them but it is not showing the updated result.
can you please take a look at it. I'll also continue to find the problem and update you if it is solved.

Also in the source tab of dev tools the code is not what i have in my vs code.

hm! I can try to help 🙂

do you have devtools local overrides turned on? perhaps you did some work inside of the sources tab on that file and hit save / ctrl + s? if so, then devtools will reload a modified file that it maintains, instead of the source file from your server. to me, this is the most likely given the screenshots and clues you've provided so far
when you run npm start in the visbug project, are there js errors? the site may continue to work and serve an older, previously built file and isnt producing a new one due to a syntax issue somewhere. tldr; it may be that a new js file isnt getting bundled, and therefore not showing your new lines of code

hm! I can try to help 🙂

do you have devtools local overrides turned on? perhaps you did some work inside of the sources tab on that file and hit save / ctrl + s? if so, then devtools will reload a modified file that it maintains, instead of the source file from your server. to me, this is the most likely given the screenshots and clues you've provided so far
when you run npm start in the visbug project, are there js errors? the site may continue to work and serve an older, previously built file and isnt producing a new one due to a syntax issue somewhere. tldr; it may be that a new js file isnt getting bundled, and therefore not showing your new lines of code

Thanks @argyleink  there are some errors while running npm start now it is working.
but can you tell me what to put in the name when we download css images because we fetch them from a url and hence can't find the name.
so should i name them like css-1,css-2,... ?

@argyleink  ??🤔

Can you give me examples of what you mean? URLs with no names?

Can you give me examples of what you mean? URLs with no names?

yaa sure
like if a image was fetch from this url https://images.unsplash.com/photo-1608806947629-da2ae50be954?ixid=MXwxMjA3fDB8MHxlZGl0b3JpYWwtZmVlZHwyfHx8ZW58MHx8fA%3D%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=400&q=60
then we don't have a name for this image then how can i name such images... I have currently  named them as css-1 , css-2 , css-3 ....

@argyleink  🤔🤔🤔

hey @argyleink  where are you ??

Vacation 😁

Vacation 😁

oh :)
when will it end ??

early january! but i can give some feedback real quick 👍🏻
some url rules?

remove all params after the ? on urls, as they're parameters and not filename values
limit filenames to 40 characters

that way really long ones can be cropped, and if they're still too long, they can be maxed out then saved. thoughts?

early january! but i can give some feedback real quick 👍🏻
some url rules?

remove all params after the ? on urls, as they're parameters and not filename values
limit filenames to 40 characters

that way really long ones can be cropped, and if they're still too long, they can be maxed out then saved. thoughts?

ya its great i'll implement it and update you

Its done @argyleink  Please review it :)

Looks ready to share! Submit a pr?

Looks ready to share! Submit a pr?

already made a pr

hey @argyleink can you please tell me how can i use this project locally with any website?
like the chrome extension has only features which are developed and as we are developing it then how can i see this project working on other websites ?

hey @argyleink can you please tell me how can i use this project locally with any website?
like the chrome extension has only features which are developed and as we are developing it then how can i see this project working on other websites ?

Here's a wiki page with some instruction: https://github.com/GoogleChromeLabs/ProjectVisBug/wiki/Local-Extension-Dev-Testing
your github repo extension/ folder will allow you to load the plugin from your computer, it'll be called DevBug in Chrome. Visit any webpage, then launch DevBug and you'll be working with your local branch and plugin against any webpage. Depending on what code changes, you may need to rebundle the extension.
Let me know if you need more help 🙂

Here's a wiki page with some instruction: https://github.com/GoogleChromeLabs/ProjectVisBug/wiki/Local-Extension-Dev-Testing
your github repo extension/ folder will allow you to load the plugin from your computer, it'll be called DevBug in Chrome. Visit any webpage, then launch DevBug and you'll be working with your local branch and plugin against any webpage. Depending on what code changes, you may need to rebundle the extension.
Let me know if you need more help 🙂

ya @argyleink I need some more help!
First of all i really like this project idea and i want to contribute more to it until i have time from my studies and all stuff.
and here at github comment section is too much slow like i usually work at night i when i see your message i reply to it at night and then i'll get your reply next night and this process goes on like it takes 2-3 days to even understand this issue.
Frankly speaking i'm new to github and don't know if github have another method of communicating rather then commenting on the issue.
It would be great if you tell me where can we communicate faster then what we are currently doing.
Also i saw the link and in the download section of it i saw this error page.

ya @argyleink I need some more help!
First of all i really like this project idea and i want to contribute more to it until i have time from my studies and all stuff.
and here at github comment section is too much slow like i usually work at night i when i see your message i reply to it at night and then i'll get your reply next night and this process goes on like it takes 2-3 days to even understand this issue.
Frankly speaking i'm new to github and don't know if github have another method of communicating rather then commenting on the issue.
It would be great if you tell me where can we communicate faster then what we are currently doing.
Also i saw the link and in the download section of it i saw this error page.

join me on Slack? https://join.slack.com/t/visbugworkspace/shared_invite/zt-l4xg8yci-QpQAv7GXl6vsm5F1uJ60qg

join me on Slack? https://join.slack.com/t/visbugworkspace/shared_invite/zt-l4xg8yci-QpQAv7GXl6vsm5F1uJ60qg


Add files via upload

new pixel

Checklist

[x] I ran npm test locally and it passed without errors.

[x] I only edited the _data/pixels.json file.

[x] I entered the username in the pixels.json that I'm also using to create this pull request.
[x] I acknowledge that all my contributions will be made under the project's license.

Hey @simonopp it seems like your contribution has been merged in the meantime. So I'm closing this one as a duplicate. Thank you for your contribution!


Add type MONEY as numeric type

fixes https://github.com/apache/incubator-superset/issues/3953

@mistercrunch Thank you!


Swift 4

Just asking, when do you think OHHTTPStubs/Swift will be compatible with Swift 4?
Thanks for your amazing job.

Hi @Jerem42,
I have to admit that I did not try to use OHHTTPStubs with Swift 4 yet.
Can you give us some details on the issues you have when using OHHTTPStubs with Swift 4?
Thanks!

Sure, here's the error when I try to import OHHTTPStubs:
Module compiled with swift 3.1 cannot be imported in Swift 4.0
The same happen if the Swift language version in the Settings is 3.2.

Can you provide some details about the integration tool you are using and follow the issue template and provide the informations it contains, please? 😊
I suspect that you are using Carthage here and I am afraid that we may not be able to support every swift version in this case 😞

Carthage is based on the idea of downloading the pre-compiled binary framework of each library you put in your Cartfile if available. Which is not a good idea until Swift is ABI stable (and discouraged by Apple for this exact reason) because then every time the compiler changes the Swift version then every binary framework is incompatible.
If you're in this situation (using Carthage to integrate OHHTTPStubs) then OHHTTPStubs will not be the only framework you'll have this issue with (every library providing a precompiled version will have the same issue). You'll have to use the --no-use-binaries flag of Carthage to about this issue with OHHTTPStubs and all other libraries you use in your Cartfile. You can find more info in Carthage's own documentation & issues.

You'll have to use the --no-use-binaries flag of Carthage to solve this issue with all other libraries you use in your Cartfile. You can find more info in Carthage's own documentation & issues.

FYI Carthage now falls back to build checked out projects if prebuilt binaries was built with different Swift version from local Swift version, so normally you will not need to add --no-use-binaries option.

Just so we know if there's still work to do on that issue: has anybody had time to test OHHTTPStubs with Xcode 9 & Swift 4 and saw any compilation issue with it or code that would need modification for it to be adapted to Swift 4?

I am using OHHTTPStubs in a Swift 4 project (installed via Carthage) and I haven't experienced any issues using Xcode beta 4. I didn't install the latest beta yet.

Cool, thanks @gonzalezreal for the feedback!
I'm gonna close this one then.
We could still reopen it in case a later beta creates issues but I doubt it since the biggest risk was with the changes in the String API and the string manipulations we do in the matchers but we'd have seen errors by now if we were affected.


Upgrading EQUIP

User Story
As an application support team, I need to ensure that the application is supportable and kept up to date.
ROC - the 3rd party supporting the application -   need to upgrade both the application and the windows servers. There is an additional request to change the way powerbi is used to report against the application.
Unfortunately ROC does not have terraform skills, so we will need to do this work for them.
We think ROC will install the software and we will then create an AMI - but this will need to be confirmed with ROC.
We should also work out how data in EQUIP will update the PowerBI server - and how PowerBI  will be accessed by users
Value / Purpose
This is to ensure that the application is supportable
Useful Contacts
<EMAIL_ADDRESS><EMAIL_ADDRESS>Additional Information
We will track this work as a standard piece of modernisation platform work
Proposal / Unknowns
Hypothesis If we... [do a thing] Then... [this will happ]
Proposal A proposal that is something testable, don't worry whether it works or not, it's a place for ideas.
Unknowns Potential pitfalls that could cause the story to expand beyond its original scope. Ideally this section will remain blank.
Definition of Done

[ ] Liaise with ROC to determine what needs doing
[ ] Document details
[ ] Create new tickets for doing the work

Andy Land
11:00
I think getting started in the Dev environment is possible pre-Christmas if you guys have availabilty - our resource for that is a guy called Jonny Davey and he's got some time in the next couple of weeks
11:01
I'm going to be away from this Friday though, so in terms of coordination we'd also loop in James Ashton from my side
11:01
tbh I think the most we can reasonably aim for is if you can get the Dev environment started up again and we get Jonny access to it - he hasn't previously had an account in the MP

New Code created to add three new windows 2022 server to development

https://github.com/ministryofjustice/modernisation-platform-environments/pull/4429

https://github.com/ministryofjustice/modernisation-platform-environments/pull/4428

The 3 servers are up and running and I have created Jonny a local administrator account on each of the servers (he has these details).

helped Jonny with his connection to the instances this is now sorted closing call


Videos aren't present in h-feed for replies

https://social.lol/@joehart/109994393527884635
https://fed.brid.gy/log?start_time=1678381252&key=https://social.lol/users/joehart/statuses/109994393527884635/activity&module=

Thanks for reporting! Looks like this is a problem with videos, not images. Should be straightforward to fix.

Should be fixed, tentatively closing. Thanks again!


Violation of ts_chainTick property

https://hydra.iohk.io/build/1932311/nixlog/4 shows us a failure of ts_chainTick property. I can successfully replicate this failure.
ts_chainTick is a property which states that, within the usual 2k-slot window, "ticking" the chain (e.g. applying the EPOCH transition and updating the delegation map, for Byron) is not affected by intermediate states - e.g. the ticks n -> n2 and n -> n1 -> n2 should be equal, for slots n < n1 < n2.  Seen another way, this property expresses the idea that the chain state should not be sensitive to which specific slots are occupied.
The above test failure shows that, for Byron, this property doesn't hold. In particular, it fails in the following circumstance. Suppose the epoch length is 10, k = 5 and the number of endorsements needed for an update proposal is just 1:

Block 0 in slot 0 contains two update proposals, proposing versions 0.1 and 1.0 respectively.
Block 1 in slot 1 contains an endorsement for PV 0.1
Block 2 in slot 2 contains an endorsement for PV 1.0
Blocks/slots 3-10 contain nothing of interest.

If the first block arrives in slot 11, then only version 0.1 will be available, and will get adopted.
If the first block arrives in slot 12, then both versions will be available, and the one to get adopted depends on the order in which they are inserted into fads.
We can resolve this by doing the epoch transition not with the current (e.g. that of the current block) slot, but with the first slot of the new epoch, regardless of the slot in which the current block arrives.

Actually realised that this will be vital for the hard fork, because as it is we cannot satisfy the "safe zone" at all.

Is this critical for the Byron release or if it's about the hard fork then is it only critical for the Shelley release?

This is critical for the hard fork, and medium priority for Byron


Pass the tenant

It's based on the https://github.com/stargate/stargate/pull/581

It's based on the https://github.com/stargate/stargate/pull/581

Closing in favor of https://github.com/stargate/stargate/pull/604

Closing in favor of https://github.com/stargate/stargate/pull/604


fix(gitbrowse): fix the regex in url_patterns

Description
The remote is used as a regex pattern, so the dot in the "github.com" means any character. This PR correct the regexes in default url_patterns.
https://github.com/folke/snacks.nvim/blob/aa38175c002555aded511b6787380ad887665680/lua/snacks/gitbrowse.lua#L40-L49
https://github.com/folke/snacks.nvim/blob/aa38175c002555aded511b6787380ad887665680/lua/snacks/gitbrowse.lua#L68-L72
Test code:
print(require("snacks").gitbrowse.get_url("https://githubacom.com/folke/snacks.nvim"))

Related Issue(s)

Screenshots
Before

After

ty!


Progress Bar for Upload

It would be nice to have a progress bar when uploading my design. Right now, I'm not sure if my design is uploading until I wait for the "upload successful" message pops up.

Note: I added the same DNA loading panel we've all grown to love :)


ChannelPipeline.SyncOperations is missing removeHandler(context:)

Expected behavior
I should be able to synchronously remove a ChannelHandler by ChannelHandlerContext, just like I can with the regular async ops... Sadly, that's not possible :|.
The fix should be pretty straightforward: Adding a func removeHandler(context: ChannelHandlerContext) throws to SyncOperations.

Note that while this will still be a sync operation, it must return a future like its partner does.

Made a PR for this!

Can this be closed?


feat: Generate coam app with NX according to #1755

#1755

Awesome, thanks for the update! Just a couple minor things and this is good to go 🙂

Updated, thanks for the feedback!


incoming call has no voice

i try to use the quick start demo to make a call to a client with client identify, the client can receive and accept the incoming call, but can not hear the both side voice, i don't know what is the problem?

Hi @wazrx
Thanks for choosing the Voice SDK and I am sorry you are experiencing this issue.
I will need your help and provide us some information so that we can take a deeper look and help you with the audio problem:

Does the same audio issue happen in your environment (device, network) with the quickstart that we provided?
Voice SDK version: I am assuming you are already using the latest version (v2.0.0) but just in case. We have added some very good improvement with audio device control in the latest release.
Call-SID: you can find the Twilio Call-SID in TVOCallInvite.callSid or TVOCall.sid.
The SDK log when the audio issue happened. .verbose would be the best.

Please note that you should not post any of your account credentials (Twilio Account SID, API key/secret) here publicly. You should be able to find my email address ;) We'll get back to you once we figure out the root cause.
Thanks.
-bobie

today i found the problem, if i open the SSR on one mobile, the no sound problem will happen, when i shut down the SSR 😳 ，everything become OK, but i still has some question， i try to connect your sale team in twilio homepage， and i send many emails and leave my phone numbers， but nobody connect to me😳， you are the first gentleman i connect successfully........

Hi @wazrx
I am sorry that you didn't receive timely help but I am also glad that you managed to solve the problem. Just curious, what does the SSR stand for?
Thanks.
-bobie
Programmable Voice iOS SDK
Twilio SDK Engineering

@wazrx thanks for the follow up! It helps a lot.
@bchen-twilio  SSR stands for shadowsocksR.

@bart2016 yes,SSR means shadowsocksR, i forget to reply this, i am glad to help you, are you Chinese developer ? we can QQ or Wexin to discuss twilio....


Ensure compatibility check readiness

Coming from https://github.com/opensearch-project/opensearch-devops/issues/114#issuecomment-1548868449
Overview
In order to detect the breaking changes between OpenSearch (core/min) and plugins, we recently onboarded a compatibility check gradle task with OpenSearch. See the pull request.
The task is dependent on publishToMavenLocal task (that publishes the core engine artifacts to maven local). It then clones the plugins' repository in temporary directory and runs ./gradlew assemble.
Action Items
In order to avoid false positives and false negatives, we need to make sure the tasks in below checklist are complete:

[ ] The build.gradle file in this repository uses mavenLocal() as the first entry in repositories() section. This will ensure that when core/min dependencies are published to maven local, gradle looks at maven local first and gets the required core/min dependencies rather than fetching from snapshots or maven central resulting in false checks.
[ ] ./gradlew assemble task passes for the plugin build. If the task itself is broken, checking compatitibility is irrelevant as it will always fail.

Please close this issue once the above checklist is complete.
Thanks!

@ylwu-amzn @vamshin  can you please provide an update?

[x] mavenLocal() as the first entry in repositories() section in build.gradle in both main and 2.x branch.
[x] ./gradlew assemble succeeds on both main and 2.x branch


How to enable xplat workflow for easy contribution

@dsyme says:
We would like to make it possible to contribute to core components that underlie the OSX and Linux experiences for F# purely by contributing to this repo (rather than the historical way of routing these requests into the fsharp/fsharp and fsharp/FSharp.Compiler.Service repos.   We can call this "repo unification".
Move to "repo unification" reflects the growing maturity of both this repo as a host for a broader range of F# work, and the growing importance of the Mono and FSharp.Compiler.Service packagings of F#.
Separately, people have discussed splitting this repo - putting the "Visual F# IDE Tools" (vsintegration and setup directories) in a separate repo, and perhaps putting "FSharp.Core"  in a separate directory too.  For now we will assume that is a a separate discussion, perhaps to be done after a round of unification work.
Here's a list of things we can reasonably unify:

[x] Mono friendly fixes and hacks from fsharp/fsharp
[ ] Mono friendly testing from fsharp/fsharp (or replacement)
[ ] "make install" or equivalent from fsharp/fsharp
[ ] local builds of nuget packages for FSharp.Core nuget (from fsharp/fsharp)
[ ] local builds of nuget packages for FSharp.Compiler.Tools nuget (from fsharp/fsharp)
[ ] code additions in Fsharp.Compiler.Service (notably some fixes and Exprs.fs) (from fsharp/FSharp.Compiler.Service)
[ ] local buidls of FSharp.Compiler.Service DLL (from fsharp/FSharp.Compiler.Service)
[ ] some extra testing (from fsharp/FSharp.Compiler.Service)
[ ] local builds of nuget packages for FSharp.Compiler.Service
[ ] type provider authoring SDK from type provider starter pack
[ ] compiling  FSharp.Compiler.Service as a Fable component, a highly valuable long term addition to the F# ecosystem that we don't want to bit-rot
[ ] make sure documentation in this repo is not skewed towards Visual Studio and Windows.  There should be a strong path where neither Visual Studio nor Windows are  assumed or even mentioned.  OSX and Linux contributors should feel "first class"
[ ] If all the above happens, then in my (@dsyme's) personal option we'd get advantage from renaming this repo to "fsharp" (even if it continues to hold the setup and vsintegrationdirectories).  fsharp/fsharp could then be a mirror of this repo
[ ] If this is the defacto fsharp compiler then a tag or versioned build need to be integrated into mono

Various problem with this plan:

[ ] This repo becomes a logjam containing everything related to both F# core engineering and the Visual F# IDE Tools.
[ ] The Windows-specific nature ("feel") of this repo will be impossible to remove while it continues to contain the Windows-specific Visual F# IDE Tools
[ ] The "make install" business currently uses a bunch of makefiles, and adds things like policy files for Mono's unification of FSharp.Core.  It's not at all clear we want to pollute this repo with that
[ ] The FSharp.Compiler.Service build process currently uses paket.  This repo doesn't.  Maybe it doesn't matter, or maybe this repo should use paket.
[ ] This repo uses some very bad things which are highly unfriendly to cross-platform contributors, like build.cmd, or testing defaults which don't work cross-platform, or a bias in the CI towards Visual Studio testing
[ ] The CI on this repo takes longer than CI on FSharp.Compiler.Service.
[ ] Supporting the Fable bootstrap of Fsharp.Compiler.Service adds a very new and different dimension to this repo that may blow the minds of contributors, and leave them unable to debug issues with Fable.
[ ] We risk making it even more complicated to contribute to F# on Mono and FSharp.Compiler.Service, since this repo does a bootstrap of the whole compiler, and the documentation on this repo is heavily skewed towards Windows users and Visual Studio contributors.
[ ] Do the new binaries and packages get signed, and if so using which strong names

Aside: this does not mean that Microsoft Visual F# Tools team become publishers of any of the alternative packagings of F# - and indeed the final "tagging" and "publishing" of these components may still be done in other repos - see this description for the actual tagging and release repos, including those used by Xamarin.  This is normal. But contributions would flow into this repo.
In addition, even after completing the unification we still expect the "fsharp/fsharp" repo to exist as a clone of this repo  (with the Visual F# IDE Tools and setup stripped out).  The mission statement of the FSSF implies that it must maintain that repo, as proof and guarantee of a fully independent existence of the F# language and tools in perpetuity.  We would probably retire the fsharp/FSharp.Compiler.Service repo, since the FCS component could always be built and published from fsharp/fsharp

@7sharp9 writes:
As a starting point I want to help with the type provider type input testing and implementation, as well as many other features but doing so means porting code to and from FCS and also building and installing the compiler into osx/mono.

I can now build and run from this repo with the resource issue: #720  I think
To get tooling support I will need to build visualfsharp and use it in place of FCS in ionide/xs/
I also need to be able to install the compiler with a script, Im assuming theres one described in the readme somewhere.

So I would need two build target outputs for this repo, one for an FCS compatible build, and one for a compiler build, and a script to install into mono.

I'm +1000 for this. Enabling @7sharp9 to contribute worth any effort needed to make FSharp.LanguageService.Compiler usable from Ionide/XS (this means to make the API optionally public I guess?)

Agreed, this is important.

At the moment Im trying to figure out how to replace the compiler installed in mono with the one just built in release, I cant see a script for that in this repo.

I added some notes here on trying to get that fork running the TP sample: https://github.com/colinbull/visualfsharp/commit/c295f8a264efeef1faed305cebbd2dbfb666ce8c

@7sharp9 @vasily-kirichenko @KevinRansom @cartermp @brettfo I've added a lengthy description of all the work I know of to be done in the area of "repo unification" up above in the issue description, plus some additional comments
@KevinRansom @cartermp @brettfo You guys are the repo owners - if you don't want these things coming in to this repo, then you should say :)

We are eager for the repos to be aligned.   And are willing to make the necessary changes to make that happen.  So long as our product pipeline is not broken by any changes we are good.

Agreed with what @KevinRansom said.  Let's do it.

@KevinRansom Thanks, that's great to know.
p.s. That said, I fear you may have a heart attack (joke!! I hope not!! :) )  when you see a PR proposing to integrate the machine-wide policy files for FSharp.Core installed as part of Mono :)  The Mono packagings of F# have always used those to unify FSharp.Core to the latest version - for better or worse.... And I assume there is code that depends on that. We can perhaps reassess that, but probably best not to do that as part of unification. So I suggest we put those under an explicit "mono" directory :)  In general we should aim to keep each of the above items fairly separable.

@vasily-kirichenko

...make FSharp.LanguageService.Compiler usable from Ionide/XS ...

Let's aim instead for building FSharp.Compiler.Service in this repo.
For now let's assume FSharp.LanguageService.Compiler remains a special version of this component used only by the Visual F# Tools.  This is because historically there was huge pressure from Visual Studio engineering to make FSharp.LanguageService.Compiler smaller - trimming out unnecessary parts.  This was to reduce overall address space usage in the 32-bit Visual Studio process.  It's possible this issue will come back to haunt us again one day, so for now just assume that the Visual F# Tools need their own special build of this component.

Disclaimer: not directly related to mono support in this repository.
Can we move the current scripts under scripts/misc and plan for a comprehensive layout for future build scripts under scripts/build?
My feeling is that we should start splitting the behemoth build.cmd into smaller independant scripts, each put in scripts/build, and have the top level build.cmd handling the main parts (setting env variables for the build conditionals, calling other .cmd, and doing the main build).
This way when we start introducing FAKE script, we can focus on a smaller set of behaviour to replicate.
individual scripts I could see:

dotnet core stuff
vssdk stuff
ngen stuff
testing stuff

I know this will make it a bit harder (but how much harder? not so much) to deal with small changes, but I don't see how the community can put effort in a big bang PR to change the whole thing at once, that will need long lead time for you guys to review / assess, while changing each small script or the top level one, one by one is definitely doable.

@smoothdeveloper Let's keep this thread on topic please, about repo unification

@7sharp9 I've updated the issue description with a list of all the problems that will arise because of repo unification.
Specifically, if we do this unification we should go into it with our eyes open: it's important that you be aware of the inevitable problems listed above (e.g. the mess that is the Windows-specific build.cmd,  or the fact that the Visual F# IDE Tools are part of this repo with all that brings in biasing it towards Windows...) .  We can fix these things, but it will require work.
The point is - don't assume unification is some kind of panacea.  It will bring new problems of a different kind.

Mostly we need to be able to do mono build and testing as part of normal dev work.

@dsyme, sorry but I think it is relevant.
For example people using windows (hence build.cmd) might also want to loopback on getting FCS built from this repository, hence I think we should make the effort of making any addition to build scripts (which are not straight ports from fsharp/fsharp or FCS repositories at least) in smaller scripts, and possibly .fsx already if we don't want another round of .sh / .cmd duplication.
Am I making any sense?

@smoothdeveloper  Yes, it makes sense.  But whether the scripts are large or small, how they are named, which directories they go in etc. is a detail we will sort out along the way.

Mostly we need to be able to do mono build and testing as part of normal dev work.

Yes, that's crucial.
@7sharp9's criteria is to be able to build and dev the core components that flow into Xamarin Studio (Visual Studio for Mac) using this repo, rather than making contributions here and then flowing them into the FCS repo.  And in general to have a first class OSX contribution story for this repo.
BTW I think I need to get myself a Mac....

so for now just assume that the Visual F# Tools need their own special build of this component.

It makes contributing by non-windows people, like @7sharp9 much more harder. There're a very few of us who contribute to FCS and cutting off #2 in this list is just unforgivable.

It makes contributing by non-windows people, like @7sharp9 much more harder. There're a very few of us who contribute to FCS and cutting off #2 in this list is just unforgivable.

I thiink I was misunderstood.  I was meaning adding something like this in this repo:
build{.sh} fcs   -- builds the FSharp.Compiler.Service
build{.sh} fcs test  -- builds and tests the FSharp.Compiler.Service
build{.sh} fcs test nuget -- builds and tests the FSharp.Compiler.Service and makes the nuget
in addition to the existing build commands (maybe the nuget is not a separate thing).
This:
build{.sh} vs   -- builds the FSharp.LanguageService.Compiler and other VS stuff
would build the separate FSharp.LanguageService.Compiler DLL from the same code for use by VS, obeying whatever extra requirements Microsoft demand.

Ah. I see. That's great. But we will end up building almost all the sources three times (FSharp.Compiler, FSharp.LanguageService.Compiler and FCS). However, if we, who use VS, won't have to build FCS in our workflow (not having it in VisualFSharp solution, basically), that's OK.

Why does there have to be 3 compilers built, is FSharp.LanguageService.Compiler the Windows / VS equivalent of FCS?

The non windows workflow would also need a compiler built and installed as well as FCS, unless there is a way of unifying both of those, or specifically decoupling the FCS parts as a facade over the compiler.

Is FSharp.LanguageService.Compiler the Windows / VS equivalent of FCS?

yes

Why does there have to be 3 compilers built

fsharp.compiler (referenced by fsc and fsi)
fsharp.languageservice.compiler for VS, it might trim down stuff with ifdef from FCS (due to memory constraint in devenv.exe)
fsharp.compiler.service

We don't need the latest one when working in VS (as @vasily-kirichenko says) and indeed it would help if the second one was just adding to the compiler itself instead of compiling again (I wonder if the reason is also related to internals?).

@dsyme I added this to the top too:

If this is the defacto fsharp compiler then a tag a versioned build need to be integrated into mono

Why does there have to be 3 compilers built

We can maybe reduce it to two or one - perhaps almost immediately after unification or even during it.  It depends in part if Microsoft continue to want internal symbols only in the VS bits they ship.  If they are ok with dropping this requirement then I reckon we can just use one FSharp.Compiler.Service.dll and nothing else.

Or ...
We can move vsintegration into a separate repo.  If Iwe were to create a new repo … github.com\microsoft\fsharp we could move the cross platform compiler there.  Limit visualfsharptools to the vsintegration and windows packaging that might make a useful factoring.
There would be internal work we have to do to support that … but perhaps it now makes sense and will at least simplify some of the build and test complexity.
Kevin
From: Don Syme<EMAIL_ADDRESS>Reply-To: Microsoft/visualfsharp<EMAIL_ADDRESS>Date: Friday, April 14, 2017 at 1:07 PM
To: Microsoft/visualfsharp<EMAIL_ADDRESS>Cc: Kevin Ransom<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Microsoft/visualfsharp] How to enable xplat workflow for easy contribution (#2854)
Why does there have to be 3 compilers built
We can maybe reduce it to two or one - perhaps almost immediately after unification or even during it. It depends in part if Microsoft continue to want internal symbols only in the VS bits they ship. If they are ok with dropping this requirement then I reckon we can just use one FSharp.Compiler.Service.dll and nothing else.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvisualfsharp%2Fissues%2F2854%23issuecomment-294204681&data=02|01|Kevin.Ransom%40microsoft.com|adbc4df1464344d99e9a08d483611dae|72f988bf86f141af91ab2d7cd011db47|1|0|636277900514415603&sdata=2%2FHA27FrI1s%2FlPcyUqAfGHIfAs5W2FU%2BIANtj0ZaHDI%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAE76FmxvOiTWVlidvKhdm1aEqhjzsQDXks5rv7XdgaJpZM4M9A3D&data=02|01|Kevin.Ransom%40microsoft.com|adbc4df1464344d99e9a08d483611dae|72f988bf86f141af91ab2d7cd011db47|1|0|636277900514425616&sdata=UNjHjpTNLrUCmaYQrpj47V0R%2Fokvx4Z9zNmQZw%2FrOOk%3D&reserved=0.

I think we all realise that any major change to code organisation is not going to happen in a reasonable time.
To me the first few steps could be:

Get the necessary extra files in here from FCS and #if deffing them so a build could be generated for FCS.  This would satisfy retiring FCS quite quickly.

The next part is getting an install script for mono, I must admit I find it hard to follow the install points in the make file in fsharp/fsharp

I noticed in the samples that the built compiler is used rather than the installed one, this is very handy rather than having to replace the compiler, unfortunately it doesn't work on osx yet.

We might want to stick to one repository for now, and be very conscious about the build scripts (split), the single code base for all is the faster turnaround, given we put attention for each step to be optimized (don't rebuild stuff, don't build 3 compilers, etc.).
But well, I'm just a random peon as they say, you guys are the one doing real work...

So Im going to take a crack at merging some bit of FCS over here and see where the #ifs go.
#if FCS
...

?

@7sharp9 I'd go with bit more verbose: #if FSHARP_COMPILER_SERVICE.

Use
#if COMPILER_SERVICE
or an existing #if

originally wrote this here
a suggestion on how we could make the alignment easier in the future - most places where #if COMPILER is used seem like types that it would be more useful to have the compiler service expose. So if we got rid of COMPILER as one of the defines for FCS add || COMPILER_SERVICE to the 10 or so places where having #if COMPILER defined was actually useful and change all of the
type (* internal *) foo = ...

to
#if COMPILER
type internal foo
#else
type foo
#endif
    (args ) =

it should cut out a bit of merge conflict resolution busywork

the COMPILER_SERVICE directive is already being used in a few places, so it makes sense to stick with that.

@KevinRansom @Pilchie @brettfo Historically Microsoft-built DLLs that are private to Visual Studio have only had internal accesiblity on their APIs.  That's one reason that forces us to have two separate DLLs - one for FSharp.Compiler.Service (public API) and one for FSharp.LanguageService.Compiler.dll (internal API, shipped with VS).
Do you know if that needs to continue to be the case?   Adding the #if is a PITA. Could we just have MIcrosoft ship a private DLL with "public" accessibility?

@7sharp9 I started some work towards supporting an installation process for Mono builds here https://github.com/fsharp/fsharp/pull/730/
It's hard to avoid just bringing the basic Makefile across, since we know it actually works on various linux distros, homebrew etc.  But I'll try to avoid bringing across all the files, and put everything in a "mono" directory

@7sharp9 @vasily-kirichenko The first of the many work items here has been completed - we now have a make install path for Mono users.  Please try it out when you get the chance.
I will now work on build fcs for building the FSharp.Compiler.Service DLL in this repo.

@7sharp9 The FSharp.Compiler.Service parts of this work are underway here: https://github.com/Microsoft/visualfsharp/pull/2951

@cartermp Note that an unfortunate side-effect of bringing FCS development into this repo would be bringing in 114 issues from that repo (though we could continue to track them in the other repo for a while while we trimmed them down).  I'll try to close out many issues there beforehand.
That's one reason I've been going through the VFT issue list today/yesterday - to trim out some old issues and make a bit of room :)

@dsyme All good to me.  More than happy to triage them so we can really know where we're at.

Ive closed some of mine that are no longer relevant or Ive forgotten
context, I think Im one of the biggest culprits :-)
On 29 April 2017 at 17:26, Phillip Carter<EMAIL_ADDRESS>wrote:

@dsyme https://github.com/dsyme All good to me. More than happy to
triage them so we can really know where we're at.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/visualfsharp/issues/2854#issuecomment-298178859,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAj7ylv34xQe8S2Qqixl7x6Lh61e4EWNks5r02S8gaJpZM4M9A3D
.

@7sharp9 @vasily-kirichenko Thank you so much for closing the swathes of old bugs, it's really immportant to keep things ship-shape

Just to mention that I'm working on a nasty PR to bring the FCS changes back into Microsoft/visualfsharp, see https://github.com/Microsoft/visualfsharp/pull/2951
There are a bunch of complications with this - there are subtle differences between FSharp.Compiler.Service.dll (public API), FSharp.Compiler.dll (internal to fsc.exe and fsi.exe) and FSharp.LanguageService.Compiler.dll (internal to VS, some things trimmed out) but it's getting there.

Just checking in / resurrecting this thread slightly.
Im just reading the build build on OS X and was wondering if there is a way of building without using mono, e.g. with only a netstandard installation.
A lot of people are getting interested in F# because of x-platform stability from netstandard and are probably not as enthralled by having to install "mono".  I know its possible to build FCS using only net standard so this should also be possible here.

I'm currently working on converting our projects over to use the new Microsoft.NET.Sdk which means you'd be able to dotnet build FSharp.Core.fsproj, etc., but due to a complicated mix of our projects, I'm first converting the Visual Studio specific projects in #4317.  While that work doesn't directly make building with only a dotnet CLI install possible, it's a step I have to take before I can re-look at converting everything under src\fsharp to the new SDK project format.

A lot of people are getting interested in F# because of x-platform stability from netstandard and are probably not as enthralled by having to install "mono". I know its possible to build FCS using only net standard so this should also be possible here.

Right now .NET Framework/Mono is still required to do any major testing, tooling work etc. in this repo
BuildFromSource should work without .NET Framework/Mono.  But there's no testing.
If it helps Mono has been rock solid for our purposes in this repo lately.  I haven't reported a bugzilla bug in about a year I think, and the only issues we've had have been xbiuld --> msbuild (which is aout convergence)  And performance is good on my Mac.

From #3015
@dsyme suggestions renaming:
FSharp.Editor --> VisualFSharp.Editor
FSharp.LanguageService --> VisualFSharp.LanguageService

Where are we with this, are we near to killing fsharp/fsharp?

This has progressed a lot, though not precisely as the checklist implies:

[x] Source build is now compliant with .NET Core source build
[x] Repo is 100% migrated to the .NET SDK with individual pieces buildable piecemeal
[x] Building itself is now simplified and can be tweaked based on the solution you want to build against and CI names now make sense
[x] README is now simplified and there is a quickstart for newcomers

Additionally:

#6549 outlines simplifying the name and dropping the "visual" part of this
FST-1008 tracks FCS being fully built and published from this repository (after it's migrated to dotnet/fsharp)

I'm going to write another RFC for archiving fsharp/fsharp, though I do see that as the last effort in this process.

I think we can reasonably close this out. FCS is now incorporated into the root of the repo and builds as a package, with release notes and docs underway. All the mono stuff is now irrelevant since we yote mono out of this repo and are unifying on the .NET SDK. The only remaining piece is emitting Fable stuff, but frankly I think Fable has been getting along fine enough without us ruining their day. Not that there aren't issues, but we've had multiple folks contribute compiler features without ever using Windows, so I consider that a success.


Lock versions for Greenkeeper to make a PR for every release

This is an ok way to make sure that we make a new feathers-client release with every release of a dependent project.

Yeah I think that works


Meeg.Kentico.ContentComponents - Pages field type

Hi Meeg
Great work by the way - I've been looking for something like this for a long time now.
I was hoping to use this with the Pages field type with the Adhoc relationships but i'm unable to select related pages. Maybe this is due to the auto generated relationship name being generated for the internal page?
Additionally if you can get the fields to line up with the others on the form/content tab it would really help. Having a seamless transition between page fields and the fields of the component will really bring it all together.
Thanks for the great work

Hi @joesouch!
Thanks for raising this issue :)
I know you know this already, but I'm only just getting around to updating it here...
I have added support for Pages fields in commit 1cb0f6b, which is in the 0.3.0 release of the NuGet packages.
I have also moved the suggestion to improve styling to issue #4.
Cheers!


fix(@electric-sql/client): The table option isn't required as a team using a proxy API might set the table there

Ah right — thanks!


Consider changing the Cosigned API ca-key to ca-cert.

This comment was not resolved and before going too far down the implementation we should address it:
https://docs.google.com/document/d/1gBLEOOHWOmvHVsoJbgGU74GdwA6CGxMRp3MAeEB50l4/edit?disco=AAAAUEBkXuM
@haydentherapper @mattmoor @coyote240 @hectorj2f @kkavitha @JimBugwadia
Just adding a few names that have been working on this, feel free to add others. I'm personally +1 on renaming.

+1 for this. Referencing the CA certificate instead of the key would be easier when setting up a policy since users won't have to extract the CA key from the certificate. It also means we can make a stronger policy - We're not just enforcing the CA key, but also the CA cert subject, expiration, etc.
I also was wondering what folks thought about making this a list of certificate chains. Currently Sigstore is just a root issuing leafs, but this may not always be the case, if we create an intermediate CA. Additionally, supporting multiple roots would be useful, say if you want to have a policy that supports the Sigstore root and a private root.

@haydentherapper @vaikas Yes, it makes sense to me. I am not sure about how common would be to support multiple roots.


GitLab 17.0 Issues

Describe the bug
Issue to track issues when running GLF vs GitLab 17.0 (release 16/05/24)
GitLabForm version
3.11.1
GitLab version
17.0.0-ee

test_schedules.py -> Is now failing on all branches, suggesting something within Schedules has changed in 17.*

@TimKnight-DWP - Do we still need to keep this issue open? If not, let's close it. Also, looks like this was specifically around scheduled pipeline related changes, which has been addressed by above PR? If yes, would be good to update the title and description of this issue for future references.

@amimas no I think this was fixed?
Closing now


RPM feedback-  A question

First of all nicely done! I have been working for over 30 years in industrial motor control, power tool control, and now lawn equipment.    I have my own Arduino-based pitch controller that I have developed.  I never really got it past prototype.   Mine is all feed-forward and uses the MPU 6050 and SPI and no active feedback.
Do I understand it correctly that the RPM feedback is filtered so you get a single pulse per electrical cycle?
Do you work about high S counts and motor back EMF damaging the comparator?

Thank you.  I'm no embedded systems expert, just a hack that cobbled together the necessary parts to make it work reasonably well.
Yes, the RPM signal conditioning circuit outputs a single pulse per electrical cycle, electrical RPM per se.
The circuit contains a resistor divider to initially lower the motor winding voltage.  The RC filtering further attenuates the signal voltage feed to the comparator.   It should be able to handle 2S up to 8S lipo batteries.  That seems to be the practical limit of the batteries currently used in control line.

I might suggest some clamping diodes or tvs diodes to clamp the max
voltage.  I can sketch it up if you like.
On Sat, Jan 6, 2024 at 9:34 AM CircuitFlyer @.***>
wrote:

Thank you. I'm no embedded systems expert, just a hack that cobbled
together the necessary parts to make it work reasonably well.
Yes, the RPM signal conditioning circuit outputs a single pulse per
electrical cycle, electrical RPM per se.
The circuit contains a resistor divider to initially lower the motor
winding voltage. The RC filtering further attenuates the signal voltage
feed to the comparator. It should be able to handle 2S up to 8S lipo
batteries. That seems to be the practical limit of the batteries currently
used in control line.
—
Reply to this email directly, view it on GitHub
https://github.com/CircuitFlyer/Climb_and_Dive/issues/1#issuecomment-1879730557,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOD7LELJG5T5KCCI6RHPIMDYNFVG7AVCNFSM6AAAAABBPSDJIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZZG4ZTANJVG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Of course, any suggestions to help better protect the circuitry would be welcome.


[Travis-ci] Enable fixture file caching to reduce test time

Current behavior
Currently when travis does its magic, it downloads the fixture file a second time when executing this line:
https://github.com/CityOfZion/neo-python/blob/cc4da934d3afc2ad46e1deb98ce638f0afd157bc/.travis.yml#L24
Expected behavior
We should configure travis-ci to cache the fixture file.
How to reproduce
re-run any build
Your environment
n/a

@metachris Travis seems to be your baby. Would you mind looking into this ? :)

I'll take a look! 👍