scipy-svn mailing list?

The https://mail.scipy.org/mailman/listinfo/scipy-svn mailing list seems to be not accepting mails sent to it from Github. The similar list https://mail.scipy.org/mailman/listinfo/numpy-svn on the other hand is accepting mail.

Is that still needed? It seems like some arcane way of backing up an SVN server that's not really needed anymore with Git.

If you want notifications about merges, similarly as it was for commits to svn. It's also a public record of pushes to git and corresponding commit hashes, which are not really tracked in git (apart from people's own cloned repos).

Okay, clear.

+1 for such a mailing list.  I find it to be quite useful in numpy, and I see no reason why scipy wouldn't benefit from it either.

Closing, not going to happen now that we don't host mailing lists any more.


My Small test

Hello everyone,
I really like Mobservable and I'm investigating whether I can use it for the scenario described below.
I want to declaratively "sync" between several objects. For instance, having three object X, Y and Z. I want to declare how those 3 "relate" to each other. So instead of triggering callbacks when one of these objects changes to update/sync the other two. I simply have the declaration dictate how the syncing must be performed.
To this end I did some tests like the one below. where two object (both having the same exact structure for this simple test) must be totally in sync (their variables must have the same values). If one changes any of the two variables the other one would automatically have the same value(s).
The idea is to have both objects totally independent from each other. The responsibility of doing the sync relies on a third system (some kind of broker).
Note that I'm using the global namespace (i.e. window) so as to be able to test this in chrome devtools (in the console)
var mobservable = require('mobservable');

window.wareHouse  = mobservable.makeReactive({ stock:0, price:5 });
window.shop           = mobservable.makeReactive({ stock:0, price:5 });

window.setSP = function(x, newStock, newPrice){ x.stock = newStock; x.price= newPrice;}

function display(name){
  console.log('Total ['+name+'] =>>>>> '+window[name].price*window[name].stock);
}

mobservable.sideEffect(function() {
  display('wareHouse');
});

mobservable.sideEffect(function() {
  display('shop');
});

mobservable.sideEffect(function() {
  console.log('wareHouse <- shop ')
  window.wareHouse.stock = window.shop.stock;
});

mobservable.sideEffect(function() {
  console.log('shop <- wareHouse');
  window.shop.stock = window.wareHouse.stock;
});

mobservable.sideEffect(function() {
  console.log('wareHouse <- shop ')
  window.wareHouse.price = window.shop.price;
});

mobservable.sideEffect(function() {
  console.log('shop <- wareHouse');
  window.shop.price = window.wareHouse.price;
});

When the code above is loaded into the browser (using chrome). I hit F12 and perform the 'tests' below. One line at a time and observe the output on the console to understand what's happening.
Remember, one line at a time.
window.setSP(window.wareHouse, 2, 7);
window.setSP(window.wareHouse, 5, 6);
window.setSP(window.wareHouse, 1, 2);

It basically works. I wonder however if it is possible with Mobservable to make it in such a way that we only have the minimum number of operations. Can we use the fact that the updating in setSP happens atomically on both variables at once to improve this ? (we'r having the syncing triggered for each variable within the setSP function. Could we have it 'trigger' just once? )
PS: I tried to group the functions inside sideEffect (syncing on both variables as the same sideEffect) but it did not work

Interesting case!
I'll try to dive into it more deeper later today, but at least in the setSP function you should be able to do
mobservable.transaction(funtion() {
    x.stock = newStock;
    x.price = newPrice;
});

Wonderful. It is working:
window.setSP = function(x, newStock, newPrice){
  mobservable.transaction(function() {
    x.stock = newStock;
    x.price = newPrice;
  });
}

Now that I think of this, this is exactly one of the situations a had on my todo list to forbid :-P.
The problem is that the side effects are not pure; they are updating the state their own execution depends on. In this case it works, but in more complex situations it can easily become hard to reason about and error prone; for examples, if the code would contain x.price = newPrice + 1, it would probably start to loop. Also it is harder to optimize.
A clean way to solve this would have a central stock and price state, and just derive he others from it:
centralState = mobservable.makeReactive({
  stock: 0,
  price: 5
});

wareHouse = mobservable.makeReactive({
  stock: function() {
    return centralState.stock
  },
  price: function() {
    return centralState.price
  },
  setStock(newStock) {
    centralState.stock = newStock;
  },
  setPrice(newPrice) {
    centralState.price = newPrice;
  }
});

That would completely avoid the need for the side effects. The set functions can probably be turned into ES5 setter for more convenient invocation.
But it depends on your use case whether you want to have such a central state. Would the above solution suffice for you? If you are creating a distributed system, the original solution makes sense and will work (and keep working), because it turns the problem in an asynchronous problem. But again beware of unending loops in such case. But within a single process, data should either be derived data, or mutable state, but not both at the same time. Just to ease the mental model of your state.
Does that make sense? Just curious about your use case!

Thanks.
I thought of the 'loop' problem and I'm fine with it (it could happen if the syncing between objects does some rounding so that the "declared equivalence" between the objects will never be 100% met).
Is there any other potential problem in the above approach?
I thought of having a 'star topology' but the former is more liberal/general. Furthermore, to the best of my understanding the code you provided above still need something like 'mobservable.transaction' to avoid triggering changes more then the "absolute minimum number of times". Also, wareHouse is aware of the centralState.
In the best of the worlds. I'd have objects that are totally unaware of each other and all syncing happens with the help of an "external broker" in the minimum number of steps :8ball:.

Yeah I can definitely see your use-case. I think the safest way to protect against looping is to update a version number upon change or distribution, and check whether your already up-to date before applying changes.
I'll close the issue for now, but don't hesitate to comment if new issues arise.

One last comment if you will. Should I conclude that the approach I've chosen is good to go?
PS: Indeed I will have to use versioning to avoid extra steps or even infinite loops.

Yes, this a valid approach for a distributed system :) For just local
system I think it is recommendable to stay with 'one truth'.
On Fri, Aug 28, 2015 at 12:00 AM, mehdi-cit<EMAIL_ADDRESS>wrote:

One last comment if you will. Should I conclude that the approach I've
chosen is good to go?
PS: Indeed I will have to use versioning to avoid extra steps or even
infinite loops.
—
Reply to this email directly or view it on GitHub
https://github.com/mweststrate/mobservable/issues/22#issuecomment-135567369
.


Patch-Endpoints for transferring only deltas

To just transfer deltas when changing data, we should introduce Patch-Endpoints

Great 👍


error code during installation

the rcompile apk does not install on android 4.2.2 ,4.3 , 4.0 ,4.1 ,3.0 ,2.3 2.6 but work on 4.4 , 5.0 ,6.1
am using apktool 2.02  smali 2.08 , baksmali 2.08

Gonna need a lot more details than that. APK, stacktrace, logcat of problem.

i decompiled an apk file that works on andriod os 4.1.2 to 5.1  and when i recompiled it that was not installing on android 4.1, 4.2 ,4.3 any longer but still works on 4.4.2,5.0,5.1
am using apktool 2.02 baksmali and smali 2.08
thanks

check minsdk/targetsdk in yml file

Let this report fall behind it seems. There isn't much to go on here even with the explanation. Need a stacktrace or APK to investigate this further.


[BUG]: no type definition for stripe.createConfirmationToken

What happened?
using:
"@stripe/react-stripe-js": "^2.6.2"
"@stripe/stripe-js": "^3.1.0"
Environment
No response
Reproduction
No response

Can you clarify exactly what you're seeing and where? Types for Confirmation Tokens were added (here) prior to yesterday's 3.1.0 release so I would expect these to be included.

@brendanm-stripe Does stripe.createConfirmationToken() support CardElement ?
For example:
const result = await stripe.createConfirmationToken({
			type: 'card',
			card: cardElement,
			billing_details: {
				name: 'test'
			}
		});

Ah, my editor was linking to an old type definition file after updating. Everything looks good!

Great, thanks for confirming @tinleym !
@felixfung203 No, at the docs suggest this is only for Payment Element and Express Checkout Element

elements REQUIRED
The Elements instance that was used to create the Express Checkout Element or Payment Element.


fix root dir

Questions
Answers

Branch?
4.4.x

Description?
I have a problem with the module ps_mbo. If we shared the directory modules with a virtual link (on CICD for exemple), the module not working.

Type?
bug fix

BC breaks?
yes / no

Deprecations?
yes / no

Fixed ticket?
Fixes #504

How to test?
Please indicate how to best verify that this PR is correct.

Possible impacts?
Please indicate what parts of the software we need to check to make sure everything is alright.

@ytilotti Looks good to me, but as PHPStan is failing, we need to investigate a bit to see what is going on and be sure that it's still working fine.

Hi team. No news?

Hello @ytilotti
We were in a rush to deliver some other features, but be sure that your PR is not forgotten.
We will do our best to validate it in the next weeks.

Thanks @ytilotti !

Thanks to you! I will be able to reactivate the update on this module.


Encrypt the router<->container link

Deis should support encrypting the router<->container hop.
My company's services must be HIPAA compliant. That means that we can't have any unencrypted personal health information (PHI) ever hitting the wire. Currently we're using Deis for internal tools with a strict no-PHI policy, but we'd like to open up usage to teams that do handle PHI.
Unfortunately, the mullet VIP (TLS in the front, party in the back) that Deis uses by default makes this impossible.
Given the current architecture of Deis, I think the only two options are:

Terminate TLS in the router, but make a new TLS connection to a container, which requires:

Add support for setting https for proxy_pass's protocol, depending on an app's config
Allow configuring a self-signed cert for the routers to trust OR let Deis generate and inject private keys into containers, which Deis is pre-configured to trust

Only Terminate TLS in the container, which requires:

Add support for setting https for proxy_pass's protocol, depending on an app's config
Configure routing affinity to allow TLS sessions to be set up and used correctly

Are there any plans for encrypting the final hop in the works?
Note that in #deis @Joshua-Anderson suggested "It could be interesting v2 feature. The k8s proxy could rencrypt traffic and then expose the keys to app containers."

@sbuss we're investigating the feasibility of adding this feature now in 1.x.  It's definitely a gap that needs to be addressed.

We are also trying to investigate it. I think that NGINX re-encrypting to the backend is probably the easiest way forward since that's supported in NGINX with the proxy ssl flag.

ping @krancour, what's the status on e2e https in v2? :)

This feature will be added in v2 and is now tracked in deis/workflow#355, as such, I am closing this.


Jumping words with CTRL + Left / Right could be improved

Operating system or device - Godot version:
Windows - Godot 2-3
Issue description:
Here's another little usability issue in the code editor that still bugs me all the time:
Navigating with CTRL + Left/Right stops at the beginning/end of the row. I can't think of any reason as of why not to proceed to previous / next row.

feel free to try your hand at text_edit.cpp
On Thu, Aug 17, 2017 at 5:40 PM, TX256<EMAIL_ADDRESS>wrote:

Operating system or device - Godot version:
Windows - Godot 2-3
Issue description:
Here's another little usability issue in the code editor that still bugs
me all the time:
Navigating with CTRL + Left/Right stops at the beginning/end of the row. I
can't think of any reason as of why not to proceed to previous / next row.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/10403, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2wYYqbSnS8UGFY-Eer0wDkN1kvzDks5sZKUogaJpZM4O6yKm
.

It's been around 15 years since my last contact with C++. However, Godot has been the very first project during that time that has almost gotten me back to it, several times. I shall install Visual Studio, and see where it gets me.


Fix errors in gene pages

These pages cause different errors

http://localhost:3000/gene/K00978
http://localhost:3000/gene/K05340
http://localhost:3000/gene/K21641

I fixed http://localhost:3000/gene/K00978 which was also causing one of the test failures.
This leaves two errors

http://localhost:3000/gene/K05340
http://localhost:3000/gene/K21641

These appear to be fixed.


SF

Just started reviewing :) :octocat: Sent from GH.

Pull request submitted to https://github.com/lawrence-lee/liferay-blade-samples/pull/46. See changes here. :octocat: Sent from GH.

Pull request submitted to https://github.com/lawrence-lee/liferay-blade-samples/pull/47. See changes here. :octocat: Sent from GH.

Pull request submitted to https://github.com/gamerson/liferay-blade-samples/pull/399. See changes here. :octocat: Sent from GH.


Extract table of content from Markdown

It would be cool to have an optional right-hand side table of content automatically generated based on the markdown file.

You mean list the sidebar items in a markdown file also?

@deekoder no I mean if a page has a set of H1, H2, H3, etc titles it would be trivial to extract a table of contents from it, for example:

This is a nice feature to have navigation inside a document!


Updates to secret santa sample

Mostly cosmetic updates to the Secret Santa sample. Was easier to do as a PR into your PR branch than to leave loads of review comments.

@delbert ping me when this is merged into your PR branch and I will approve the PR into microsoft/qio-samples.


Update step-02/js/main.js

Hi.
We need to know when video and audio are not available.

@googlebot I signed it!


mfrc522 constantly returns "IRQ error" after first read

Describe the bug
After calling *Dev.ReadCard() for the first time, subsequent calls always immediately return the error mfrc522 lowlevel: IRQ error (which is thrown in low_level.go:326 for unexplained reasons - seems like the timer interrupt is enabled according to the datasheet?!). If a card is present during the call to ReadCard, it will be read normally, but the interrupt is not working anymore.
To Reproduce
Steps to reproduce the behavior:

Create program

package main

import (
	"fmt"
	"periph.io/x/periph/conn/gpio/gpioreg"
	"periph.io/x/periph/conn/spi/spireg"
	"periph.io/x/periph/experimental/devices/mfrc522"
	"periph.io/x/periph/experimental/devices/mfrc522/commands"
	"periph.io/x/periph/host"
	"time"
)

func assertNil(v interface{}) { if v != nil { panic(v) } }
func assertNotNil(v interface{}) { if v == nil { panic(v) } }

func main() {
	_, err := host.Init()
	assertNil(err)

	port, err := spireg.Open("SPI0.0")
	assertNil(err)

	reset := gpioreg.ByName("149")
	assertNotNil(reset)

	irq := gpioreg.ByName("200")
	assertNotNil(irq)

	conn, err := mfrc522.NewSPI(port, reset, irq)
	assertNil(err)

	ver, err := conn.LowLevel.DevRead(commands.VersionReg)
	assertNil(err)
	fmt.Printf("Chip Version: %v\n", ver)

	for {
		data, err := conn.ReadCard(-1, commands.PICC_AUTHENT1A, 1, 0, mfrc522.DefaultKey)
		if err == nil {
			fmt.Printf("Card Data: %x\n", data)
		} else {
			fmt.Printf("Card Error: %s\n", err)
		}
		time.Sleep(500 * time.Millisecond)
	}
}

Run it.
Touch a card against the reader -> will be read
Remove the card -> IRQ errors start showing up:

Restart the program -> "fixes" the error, we're now at step 2 again

Expected behavior
When running ReadCard multiple times, I should get the same result as the first time (i.e. waiting for an interrupt to occur).
Platform (please complete the following information):

OS: Poky from Yocto Project (with sysfs GPIO)
Board: Jetson Nano Developer Kit

Closing & reopening the port is a workaround (see below), but I couldn't find any code called by NewSPI() that could solve this problem and is not also called from ReadCard()...
assertNil(port.Close())
port, err = spireg.Open("SPI0.0")
assertNil(err)
conn, err = mfrc522.NewSPI(port, reset, irq)
assertNil(err)

Thanks a lot for detailed report! Can you confirm the interrupt line with an oscilloscope? If not, we'll probably need help with debugging this.

Thanks a lot for detailed report! Can you confirm the interrupt line with an oscilloscope? If not, we'll probably need help with debugging this.

I am facing the same issue, here's a trace of the IRQ line:

It's reading the UID 3 times then you see the issue trailing off after that, so the IRQ line is falling but I'm unsure if that's before or after the error is seen.
Code

package main

import (
	"encoding/hex"
	"log"
	"time"

	"periph.io/x/periph/conn/spi/spireg"
	"periph.io/x/periph/experimental/devices/mfrc522"
	"periph.io/x/periph/host"
	"periph.io/x/periph/host/rpi"
)

func main() {
	if _, err := host.Init(); err != nil {
		log.Fatal("Failed to init periphio: ", err)
	}

	p, err := spireg.Open("")
	if err != nil {
		log.Fatal("Failed to open spireg: ", err)
	}

	nfc, err := mfrc522.NewSPI(p, rpi.P1_22, rpi.P1_18)
	if err != nil {
		log.Fatal("Failed to init MFRC522: ", err)
	}
	defer nfc.Halt()

	for {
		uid, err := nfc.ReadUID(10 * time.Second)
		log.Printf("UID: %s, err: %s", hex.EncodeToString(uid), err)
	}
}

Log
alan@brackenpi:~ $ ./mfrc522test
2021/03/06 15:50:00 UID: f76783d97e, err: %!s(<nil>)
2021/03/06 15:50:00 UID: f76783d97e, err: %!s(<nil>)
2021/03/06 15:50:00 UID: f76783d97e, err: %!s(<nil>)
2021/03/06 15:50:00 UID: , err: mfrc522: back data expected 5, actual 1
2021/03/06 15:50:00 UID: , err: mfrc522 lowlevel: IRQ error
2021/03/06 15:50:00 UID: , err: mfrc522 lowlevel: IRQ error
2021/03/06 15:50:00 UID: , err: mfrc522 lowlevel: IRQ error
2021/03/06 15:50:00 UID: , err: mfrc522 lowlevel: IRQ error
2021/03/06 15:50:00 UID: , err: mfrc522 lowlevel: IRQ error
2021/03/06 15:50:00 UID: , err: mfrc522 lowlevel: IRQ error
2021/03/06 15:50:00 UID: , err: mfrc522 lowlevel: IRQ error
2021/03/06 15:50:00 UID: , err: mfrc522 lowlevel: IRQ error
2021/03/06 15:50:01 UID: , err: mfrc522 lowlevel: IRQ error
... etc

Happy do do more debug.

This is interesting: https://github.com/google/periph/blob/2d212de54aa9510afd901f8faafd8c665e3d441f/host/sysfs/gpio.go#L191-L192

Yeah that's a separate work item. It's possible that edges are missed. It's fairly rare on RPi but on AllWinner based CPUs it's sadly totally unreliable.

I see. Do you think It's the MFRC522 interrupting immediately (even without a tag) and the code reading that as an error somehow, or do you think the interrupt line falling is just an artefact of the repeated read attempts?

I have no idea, I never used this device myself.

When reading a UID once there are always two device interrupts, as seen above. There is only one call to gpio.PinIn.WaitForEdge() at the start of selectCard, this means that the next call to WaitForEdge will return immediately as there has been an edge since the last call. So we either need to either prevent the second device interrupt from happening or service the host interrupt appropriately.
https://github.com/google/periph/blob/688e66ebfa5a498d3cf9b55f2233db0edd90754d/experimental/devices/mfrc522/commands/low_level.go#L402
The device interrupt selected (above) interrupts when "receiver has detected the end of a valid data stream". We will get many of these during any transaction, and apparently at least one if we try to read with no card present as this condition doesn't clear itself after one failed read. There doesn't appear to be a more fine grained interrupt available, so it looks like we have to pick a sensible point to service the host GPIO interrupt.
I think we can call WaitForEdge(0) before line 198 in low_level.go: https://github.com/google/periph/blob/master/experimental/devices/mfrc522/commands/low_level.go#L196-L209
This will clear the host GPIO interrupt before we asynchronously call WatForEdge(timeout), we don't expect a device interrupt until after ComIrqReg is cleared by line 207.
I also realise this whole conversation should probably move to this repo? https://github.com/periph/devices

Yes, I didn't transfer the issues to the new repos yet. I just realized it's actually fairly easy, it's just a bit tedious as I have to do it for individual issues. Will try on an inactive issue first to confirm it works.

Attempting to migrate an issue results in a 500 (!) so let's stick it here for now.


Flips 3.0 Design Proposal

Thinking some more about this, it would make sense to split the library into the domain / types parts (everything to build a Model object) and then have separate libraries for each solver which implement translation of Model back and forth with specific solver backends and provide the same simplified API as currently in the Solver module.
Using discriminated unions for the solver type and putting it in the Settings record is not the right approach.
The split between the three stages would remain :

formulation
runtime
result extraction

but the runtime part would be opened up, while remaining simple for the simplest use cases:
// formulation
let formulation : Model =
   Model.create ...

// runtime
let solver = Flips.Solver.GoogleOrTools.Solver.createSolver Flips.Solver.GoogleOrTools.SolverSettings.basic
let result = Solver.solve formulation solver

// result extraction
match result.Status with
| Optimal ->
  result.Decisions
  result.Objectives
| _ -> ...

For the specific solver settings, studying how Feliz model typed DSL over HTML format in a way which is convenient to use.
I think such API would benefit more advanced use case, also the benefit of splitting the assemblies / nuget packages, then you can reference only the model in projects dealing with formulation and handling the results back, and break down the dependencies in solver specific packages into Flips.Solver.* runtime packages.
Proposed assemblies:

Flips everything up to Model
Flips.Solver the abstraction defining the SolveResult and interface for running the solver with settings and mapping the results back to the Model
Flips.Solver.GoogleOrTools backend using google-ortools, implementing the interfaces in Flips.Solver
...

I really like this direction. I’d like to think about this and put together some examples of what the code would look like with the new layout. I want the “ergonomics” of the library to be really clean and composeable. Modeling SolverType as a DU was a mistake.
The other thing I keep top of mind is simplicity for a new developer. I’m wanting to keep simple things simple while enabling more complex business scenarios.
Would we want to include a default solver? Would the user need to download a single library or one for the base and one for the solver they want to use?

Another thing I’m noting for my own sake. Exposing the Settings type was a mistake. Any user that builds that type using the Record construction syntax will have their code break if we add a field. Didn’t see that coming but needs to be fixed so we can continually add features without breaking code.

@matthewcrews thanks for the feedback.

I’m wanting to keep simple things simple while enabling more complex business scenarios.

We can make sure of preserving the simplicity for end users, which is one highlight of this library and a fundamental design principle.
It would boil down to opening a new namespace, the same way usage of Flips.UnitsOfMeasure happens, the namespace would be the one bringing up the easy to use Solver module of a specific backend.
There is some attention to be put in case code wants to use several solver backends, so that the types/modules don't get name-erased but I think this would be viable route for the API to remain almost identical.
We can also follow consistent naming conventions to avoid name-erasing:
open Flips.Solver
open Flips.Solver.GoogleOrTools.Solver
open Flips.Solver.Optano.Solver
let ortoolsSolver = Solver.createWithGoogleOrToolsSettings SolverSettings.GoogleOrTools.basic
let optanoSolver = Solver.createWithOptanoSettings SolverSettings.Optano.basic

There may be some redundancy in the implementation of those backend specific modules, but it is implementation detail and can be ironed out after maintaining the specific backends on their own.

Would we want to include a default solver?

I would say no, some reasons:

heavy weight dependency to bring all of the supported backends (especially in script references)
in projects, transitive dependencies get pulled automatically via nuget or paket, if I reference Flips.Solver.GoogleOrTools it will pull all the right things to be ready to run.

We could even provide a compatibility solver module which implements the current way it is done.

The more I think about this, the more I think the modeling of the problem and the solving of the problem should be made distinct. The implication is that the Solution type is not defined in Flips but instead in a different library. Flips.Solver for example. Flips.Solver is just a tiny project which declares the basic ISolver interface and the Solution type.
The Flips.Solver.Legacy project declares equivalent types to the old Flips types. The newer solvers can diverge and provide more bespoke instances.

@matthewcrews I concur with your analysis.
Your approach is "deffer design decision" and Flips at it's core is excellent library to express the model and run it to get one shape of solution object with minimum moving parts.
The only public thing I see for now as identical in each solver implementation is a datastructure to map from solver backend variables, constraints, objectives types to those from Flips and the other way around.
The particular service done by this datastructure should roughly have the minimal contract of what the Solution module was doing.
Then we can have an implementation of Solution module which works with the shared common denominator solution which is object storing the model and with a mapping of last results from the solver.
There will be a bit of variation on how the solution object is defined and how the solver is handling the processing for each backend but we should still be able to generalize the "visiting of the model" part to ease the work of making a naive Flips model -> Solver backend implementation.

For consideration also, it would be good to allow client code to define their own "polymorphic" Decision and LinearExpression objects, the reason it is useful is that you can have your own type storing extra domain / application specific information without dealing with an extra mapping in your application logic.
type MyVariable(lb, ub, name, myDomainData) =
  interface IDecision with
     member x.Type = Continous
     // ...

  member x.UserFriendlyName = $"the amount of {myDomainData.SomethingName} per {name} produced"

Does that make sense?

Does that make sense?

Interesting. Yes, that does make sense. I'm thinking through the design implications as I look forward. Per our discussions, my mental model divides the process of optimization into the following activities:

Build/Update the Model
Solve/Resolve the Model
Inspect the Solution

I say Build/Update and Solve/Resolve because this process can actually be a loop. You create an initial model, solve it, inspect the solution, update the model, and resolve. That is exactly what the Multi-Objective Function feature actually does, it's just hidden from the user.
I see the potential that would be enabled by defining interfaces that client code could implement. I'm curious if all the operators would work though. A lot of the code in Flips is just defining operators for how types interact (+, -, ==, <==, >==). I think seeing use cases would help guide that design.
I like the idea of keeping the stages and responsibilities separate and clean. The Flips library is about modeling the problem. The Solvers are for solving a model and inspecting the solution. There is a minimal ISolver interface which governs the base capabilities.
Something that needs to be addressed though is being able to update an existing model and re-solve. I have not thought about that other than for the Multi-Objective Function feature. It's not possible to remove or update a constraint at this time. That's not good if you want to support an iterative solve workflow. Is it something we want to support? Is it something we want to make simple? Right now a Model has a list of Constraint and that's really simple to work with. Needing to index into that would get ugly. What would the indexer for the Constraint even be?
I'm not sure this is something at this moment but it is something that I am mulling. Right now I like the simplicity of having a Solution which you use as a parameter to evaluate the results of LinearExpression or Objective. A Solution really is just the values of the decision variables the solver found. Another useful thing would be to surface the Shadow Prices of constraints as well.

I've been working on separating concerns between Flips and Flips.Solver. I like the idea of defining interfaces for IDecision, ILinearExpression, IConstraint, and IModel. I see how it enables a lot of flexibility going forward. One concern I have going forward though is the reduction of LinearExpression. float math can get messy and the LinearExpression.Reduce function goes to a lot of effort to make float math behave deterministically. These kind of bugs can be really difficult to identify.
The place where this really matters is in testing for equality of LinearExpression. If the float math is not done properly, you can get some bizarre behaviors.

One of the challenges is what will the interface for ILinearExpression be?

Since it is unclear, if needed or to give a look, the first step would be to define it with same abilities as LinearExpression has, and seeing what happens.
For example, I've started to explore a bit defining interface for CPLEX settings, and on top of a "rigid" DU that I'm just using for now:
https://github.com/matthewcrews/flips/blob/340c2f0892e1e159ac05391508253001797f637e/Flips.Solver.Cplex/CplexSolver.fs#L159-L178

What would a Solver instance expect?

I recommend we start with what Flips define, the concrete Model and everything in it, later on we can bring interfaces with remaining compatible (so long Flips concrete types define it) if need be.
The solution object could be an interface with lookup function to get a decision by it's name, or an array of those, to help performing routine operations a model may do.
type ISolution =
  abstract GetDecisionValue : decision: DecisionName -> float
  abstract GetExpressionValue : expr: LinearExpression -> float
  abstract GetDecisionValueRange : decisions: DecisionName array -> float array
  abstract FillWithDecisionValues : decisions: DecisionName array -> buffer: float array -> startIndex: int -> unit

Flips.Solver may also define a simple implementation of it taking IReadOnlyDictionary<DecisionName,float> as input.
Those are just some proposals.

In the dev branch, I see a lot of InternalsVisibleTo being used to expose things to downstream projects.  I don't recommend releasing like this.  One reason is that it puts potential additional solvers outside this solution at a disadvantage because they have access to a smaller API.
Maybe this is just a temporary thing while lots of code is being moved around.

Completely agreed. It was temporary thing to unblock some work until new interfaces were defined.

@TysonMN also concur, it is temporary and I'd recommend just using internal namespace with things being public while things are in flux.
@matthewcrews, I think it would be good to gather an action plan to streamline the work on dev on the different areas. I'm myself not pushing on the external surface of the cplex solver API due to waiting where we are taking the breaking down of the API.
I think if more people can contribute bindings to solvers in "work in progress" mode in dev branch, it will give us more foot print to evaluate the things we can abstract or should leave on the solver side.
Similarly about the client code which defines the model and uses Flips, we should also introduce code which looks more like real world in term of size and workflow from the model to the domain output, even if just to get a better feel of what changes in the API imply against such code.

Proposed assemblies:

Flips everything up to Model
Flips.Solver the abstraction defining the SolveResult and interface for running the solver with settings and mapping the results back to the Model
Flips.Solver.GoogleOrTools backend using google-ortools, implementing the interfaces in Flips.Solver
...

Even being new to Flips, I immediately see the benefit of having packages like Flips.Solver.GoogleOrTools.  On the other hand, I don't see the advantage of separating Flips and Flips.Solver.

Would we want to include a default solver?

I would say no...

I agree with @smoothdeveloper.
As an example for comparison, I really like the logging library Serilog.  However, almost every user of Serilog also depends on some sink, which is the term used by Serilog to describe the location where log events are sent.  Want to log your events to the console?  Then you should use Serilog.Sinks.Console.  Want to log your events to a file?  Then you should use Serilog.Sinks.File.  Here is a list of sinks for Serilog.  Many of them were created by the creator of Serilog, but some of them were created by others.  My favorite such example is Serilog.Sinks.XUnit.
I think that is what you hope the future will look like for this library.  The core Flips code is independent of a particular solver, some solver-specific packages are created in-house, and others in the community eventually create additional solver-specific packages.
As another comparison, there is no NuGet package called Serilog.Sinks.  Instead, the interface for sinks is in the Serilog NuGet package.  In the same way, I expect everything currently in Flips.Solver in the dev branch to also be in Flips.

I like the idea of defining interfaces for IDecision, ILinearExpression, IConstraint, and IModel. I see how it enables a lot of flexibility going forward.

I don't see that, but of course I am new to Flips.  Would it be reasonable to first split out the solvers into their own NuGet packages and only then consider the additional advantage gained by adding any of these four interfaces?

One concern I have going forward though is the reduction of LinearExpression. float math can get messy and the LinearExpression.Reduce function goes to a lot of effort to make float math behave deterministically. These kind of bugs can be really difficult to identify.
The place where this really matters is in testing for equality of LinearExpression. If the float math is not done properly, you can get some bizarre behaviors.

That is what #141 is about.  My guess is that there are values for which the properties under test fail because of rounding during floating point arithmetic but those values are either outside of the range currently being considered by the tests or have yet to be found by the tests.

type ISolution =
 ...
  abstract FillWithDecisionValues : decisions: DecisionName array -> buffer: float array -> startIndex: int -> unit

Is this mutation crucial for performance?  If not, functional style would be to return another ISolution and make the behavior pure.
abstract FillWithDecisionValues : decisions: DecisionName array -> buffer: float array -> startIndex: int -> ISolution

I'm not sure this is something at this moment but it is something that I am mulling. Right now I like the simplicity of having a Solution which you use as a parameter to evaluate the results of LinearExpression or Objective. A Solution really is just the values of the decision variables the solver found. Another useful thing would be to surface the Shadow Prices of constraints as well.

I was thinking of adding an issue with a feature proposal, but I saw you had considered this already here. The shadow prices would be crucial for most of my use cases, so they would be really appreciated.

Something that needs to be addressed though is being able to update an existing model and re-solve. I have not thought about that other than for the Multi-Objective Function feature. It's not possible to remove or update a constraint at this time. That's not good if you want to support an iterative solve workflow. Is it something we want to support? Is it something we want to make simple? Right now a Model has a list of Constraint and that's really simple to work with. Needing to index into that would get ugly. What would the indexer for the Constraint even be?

Iterating a solution using an existing model by changing an individual parameter / coefficient might be useful as well, but that might require more drastic changes.
Just my three cents. Thanks for the effort so far, the planned updates seem promising!

I'm not sure this is something at this moment but it is something that I am mulling. Right now I like the simplicity of having a Solution which you use as a parameter to evaluate the results of LinearExpression or Objective. A Solution really is just the values of the decision variables the solver found. Another useful thing would be to surface the Shadow Prices of constraints as well.

I was thinking of adding an issue with a feature proposal, but I saw you had considered this already here. The shadow prices would be crucial for most of my use cases, so they would be really appreciated.

Something that needs to be addressed though is being able to update an existing model and re-solve. I have not thought about that other than for the Multi-Objective Function feature. It's not possible to remove or update a constraint at this time. That's not good if you want to support an iterative solve workflow. Is it something we want to support? Is it something we want to make simple? Right now a Model has a list of Constraint and that's really simple to work with. Needing to index into that would get ugly. What would the indexer for the Constraint even be?

Iterating a solution using an existing model by changing an individual parameter / coefficient might be useful as well, but that might require more drastic changes.
Just my three cents. Thanks for the effort so far, the planned updates seem promising!

@okkehattu thank you for the thoughts. When I started this work the documentation for the GLOPS solver was sparse for .NET which is why Shadow Prices were not included. There's also the problem of the access pattern. A Shadow Price is associated with a Constraint and there's not real concept of a indexed collection of constraints.
Could you provide some example use cases of what you would like to do? That would help guide the design discussion. Flips was not originally designed with iterative solve scenarios in mind. Right now you need to rebuild/resolve the model each time. That's adequate for my uses cases but I am only one perspective.

@okkehattu thank you for the thoughts. When I started this work the documentation for the GLOPS solver was sparse for .NET which is why Shadow Prices were not included. There's also the problem of the access pattern. A Shadow Price is associated with a Constraint and there's not real concept of a indexed collection of constraints.
Could you provide some example use cases of what you would like to do? That would help guide the design discussion. Flips was not originally designed with iterative solve scenarios in mind. Right now you need to rebuild/resolve the model each time. That's adequate for my uses cases but I am only one perspective.

Even being new to Flips, I immediately see the benefit of having packages like Flips.Solver.GoogleOrTools. On the other hand, I don't see the advantage of separating Flips and Flips.Solver.

I'm wrestling with this same point. For now it's two different projects. It would be relatively simple to merge them. Any solver backend though would likely include Flips.Solver as a dependency so you would likely get it for free anyway.

Even being new to Flips, I immediately see the benefit of having packages like Flips.Solver.GoogleOrTools. On the other hand, I don't see the advantage of separating Flips and Flips.Solver.

I'm wrestling with this same point. For now it's two different projects. It would be relatively simple to merge them. Any solver backend though would likely include Flips.Solver as a dependency so you would likely get it for free anyway.

On the other hand, I don't see the advantage of separating Flips and Flips.Solver.

I expect everything currently in Flips.Solver in the dev branch to also be in Flips.

In my initial comment, I think I made that split for some of those reasons:

the model and numerical parts of Flips are already quite solid and will probably be updated less frequently
I expect most of the upcoming "involved code additions" to revolve around the "runtime" part, which match with Solver kind of activities, knowing there will be several backend, it made sense to have a place to accrete code that helps implementing the solvers, but those concerns are orthogonal to the other parts
from client code perspective, it is nice option to be able to split the "formulation" and "extraction" parts from the "runtime/solving" one even in terms of dependencies
as @matthewcrews says, when you use dependency manager to pull a solver, it doesn't really matter that the assembly is separate, it will bring both Flips and Flips.Solver

I don't really see any drawback with all those elements.

A Shadow Price is associated with a Constraint and there's not real concept of a indexed collection of constraints.

This brings back the requirement to store them in structure using the hashcode

Could you provide some example use cases of what you would like to do? That would help guide the design discussion. Flips was not originally designed with iterative solve scenarios in mind. Right now you need to rebuild/resolve the model each time. That's adequate for my uses cases but I am only one perspective.

Hopefully @okkehattu  will have some ideas to share around the iterative solving approach, I'm also interested in that area in terms of extensibility, I don't remember fine details of models I've seen using those techniques, but it was looking a bit like that

solve problem with smaller set of fundamental constraints
check all the extra constraints failed, and depending the logic, adjust the decision in the formulation, or add more constraints
loop until reaching solved in terms of both the solver and domain criteria

I know the shadow price is also used in my domain, having some of those concepts surfacing in Flips and a bit of documentation around the topic would be great.

On the other hand, I don't see the advantage of separating Flips and Flips.Solver.

I expect everything currently in Flips.Solver in the dev branch to also be in Flips.

In my initial comment, I think I made that split for some of those reasons:

the model and numerical parts of Flips are already quite solid and will probably be updated less frequently
I expect most of the upcoming "involved code additions" to revolve around the "runtime" part, which match with Solver kind of activities, knowing there will be several backend, it made sense to have a place to accrete code that helps implementing the solvers, but those concerns are orthogonal to the other parts
from client code perspective, it is nice option to be able to split the "formulation" and "extraction" parts from the "runtime/solving" one even in terms of dependencies
as @matthewcrews says, when you use dependency manager to pull a solver, it doesn't really matter that the assembly is separate, it will bring both Flips and Flips.Solver

I don't really see any drawback with all those elements.

A Shadow Price is associated with a Constraint and there's not real concept of a indexed collection of constraints.

This brings back the requirement to store them in structure using the hashcode

Could you provide some example use cases of what you would like to do? That would help guide the design discussion. Flips was not originally designed with iterative solve scenarios in mind. Right now you need to rebuild/resolve the model each time. That's adequate for my uses cases but I am only one perspective.

Hopefully @okkehattu  will have some ideas to share around the iterative solving approach, I'm also interested in that area in terms of extensibility, I don't remember fine details of models I've seen using those techniques, but it was looking a bit like that

solve problem with smaller set of fundamental constraints
check all the extra constraints failed, and depending the logic, adjust the decision in the formulation, or add more constraints
loop until reaching solved in terms of both the solver and domain criteria

I know the shadow price is also used in my domain, having some of those concepts surfacing in Flips and a bit of documentation around the topic would be great.

I am in agreement with @smoothdeveloper  but I'm open to this being a discussion. I think the library/package separation really needs to be driven by real world use cases. I like the "simplicity" of having a package that is all about problem/model formulation and separate ones for interpreting the model. I think core Flips has done this fairly well at easing model formulation.
We still face a problem of wanting to remove/update/add an existing constraint/objective and re-solving. This gets a little complicated though because you want to update the Solver Model Instance as well, not just the Flips model. The Solver Model Instance is a separate representation from the Filps model. I don't have a good answer here. I think some real world use cases will really clarify what we want to be able to do.
What would you want to index a collection of constraints by? Do you just need the hashcode? That seems kind of clunky to me, but I don't know.
I think returning Shadow Prices can be returned via a function which takes a Solution as an input. For example:
let shadowPrice = Constraint.shadowPrice solution constraint

I like the idea of exposing additional functionality as functions because it makes extensibility going forward easier. F# really encourages the separation of types from functions that operate on those types and I tend to favor that. Again, there's are opinions but I'm open to being corrected with real world use cases.

I am in agreement with @smoothdeveloper  but I'm open to this being a discussion. I think the library/package separation really needs to be driven by real world use cases. I like the "simplicity" of having a package that is all about problem/model formulation and separate ones for interpreting the model. I think core Flips has done this fairly well at easing model formulation.
We still face a problem of wanting to remove/update/add an existing constraint/objective and re-solving. This gets a little complicated though because you want to update the Solver Model Instance as well, not just the Flips model. The Solver Model Instance is a separate representation from the Filps model. I don't have a good answer here. I think some real world use cases will really clarify what we want to be able to do.
What would you want to index a collection of constraints by? Do you just need the hashcode? That seems kind of clunky to me, but I don't know.
I think returning Shadow Prices can be returned via a function which takes a Solution as an input. For example:
let shadowPrice = Constraint.shadowPrice solution constraint

I like the idea of exposing additional functionality as functions because it makes extensibility going forward easier. F# really encourages the separation of types from functions that operate on those types and I tend to favor that. Again, there's are opinions but I'm open to being corrected with real world use cases.

I'm open to this being a discussion.

Just to be clear, with what I stated, I also look for having more insight on the motives of split or keeping Flips.Solver together from others' perspective.
For now, it only felt related to nuget publishing and consumption, and in current dotnet eco system, I don't see the separate assembly/package as a problem.
The points about versioning also didn't come the time of the top comment of this issue, but in me looking at comments / inquiries about those considerations.

This gets a little complicated though because you want to update the Solver Model Instance as well, not just the Flips model. The Solver Model Instance is a separate representation from the Filps model. I don't have a good answer here. I think some real world use cases will really clarify what we want to be able to do.

@matthewcrews sketching few ideas around it:
We could develop a DSL for updating a "live" model, it would have a grammar of operations as a DU, that could be used to update the decision boundaries, add / remove constraints.
It could maybe even fit in the Model algebra of functions that exists right now and remain coherent.

The Solver Model Instance is a separate representation from the Filps model. I don't have a good answer here. I think some real world use cases will really clarify what we want to be able to do.

In the CPLEX backend, for now I have this:
https://github.com/fslaborg/flips/blob/e54f8c5211677ed874d0f925b17011bf4d4aa692/Flips.Solver.Cplex/CplexSolver.fs#L389-L397
this allows to potentially implement those operations, at least on the cplex side.

What would you want to index a collection of constraints by?

I may have misunderstood, but it felt that end result of extracting shadow prices would conceptually be a Map<Constraint,float>, or a dictionary, and that there was use for Constraint as key.
But for your questions, I don't think the questions that involve "what should we index X by?" are to be solved in Flips, because those decisions pertain to what makes sense in context of the client code. The question applies to the internal implementation details of course, but not so much for the public API surface.

I think returning Shadow Prices can be returned via a function which takes a Solution as an input. For example:

+1, this looks consistent to how extraction of decision values is done

I like the idea of exposing additional functionality as functions because it makes extensibility going forward easier. F# really encourages the separation of types from functions that operate on those types and I tend to favor that. Again, there's are opinions but I'm open to being corrected with real world use cases.

+1

I'm open to this being a discussion.

Just to be clear, with what I stated, I also look for having more insight on the motives of split or keeping Flips.Solver together from others' perspective.
For now, it only felt related to nuget publishing and consumption, and in current dotnet eco system, I don't see the separate assembly/package as a problem.
The points about versioning also didn't come the time of the top comment of this issue, but in me looking at comments / inquiries about those considerations.

This gets a little complicated though because you want to update the Solver Model Instance as well, not just the Flips model. The Solver Model Instance is a separate representation from the Filps model. I don't have a good answer here. I think some real world use cases will really clarify what we want to be able to do.

@matthewcrews sketching few ideas around it:
We could develop a DSL for updating a "live" model, it would have a grammar of operations as a DU, that could be used to update the decision boundaries, add / remove constraints.
It could maybe even fit in the Model algebra of functions that exists right now and remain coherent.

The Solver Model Instance is a separate representation from the Filps model. I don't have a good answer here. I think some real world use cases will really clarify what we want to be able to do.

In the CPLEX backend, for now I have this:
https://github.com/fslaborg/flips/blob/e54f8c5211677ed874d0f925b17011bf4d4aa692/Flips.Solver.Cplex/CplexSolver.fs#L389-L397
this allows to potentially implement those operations, at least on the cplex side.

What would you want to index a collection of constraints by?

I may have misunderstood, but it felt that end result of extracting shadow prices would conceptually be a Map<Constraint,float>, or a dictionary, and that there was use for Constraint as key.
But for your questions, I don't think the questions that involve "what should we index X by?" are to be solved in Flips, because those decisions pertain to what makes sense in context of the client code. The question applies to the internal implementation details of course, but not so much for the public API surface.

I think returning Shadow Prices can be returned via a function which takes a Solution as an input. For example:

+1, this looks consistent to how extraction of decision values is done

I like the idea of exposing additional functionality as functions because it makes extensibility going forward easier. F# really encourages the separation of types from functions that operate on those types and I tend to favor that. Again, there's are opinions but I'm open to being corrected with real world use cases.

+1

I agree with @smoothdeveloper; I don't see any significant downside to separate Flips and Flips.Solver projects.  It just isn't the choice that my intuition says is the right one at this stage of refactoring.  I will keep this separation in mind as the refactoring continues.

I agree with @smoothdeveloper; I don't see any significant downside to separate Flips and Flips.Solver projects.  It just isn't the choice that my intuition says is the right one at this stage of refactoring.  I will keep this separation in mind as the refactoring continues.

Could you provide some example use cases of what you would like to do? That would help guide the design discussion. Flips was not originally designed with iterative solve scenarios in mind. Right now you need to rebuild/resolve the model each time. That's adequate for my uses cases but I am only one perspective.

I don't have a use case at this point. Could be useful for performance (or convenience) reasons, but I'm at least not seeing that as a problem so far and the iteration can easily be done on a higher level on the application side.

Could you provide some example use cases of what you would like to do? That would help guide the design discussion. Flips was not originally designed with iterative solve scenarios in mind. Right now you need to rebuild/resolve the model each time. That's adequate for my uses cases but I am only one perspective.

I don't have a use case at this point. Could be useful for performance (or convenience) reasons, but I'm at least not seeing that as a problem so far and the iteration can easily be done on a higher level on the application side.

Something that I started to formulate in my head is a way to support the iterative workflow of:

Build initial Model
2 Solve Model
Evaluate Solution

If solution good

Done

If not

Update model, return to 2

This would be a really useful way of iteratively exploring a model. Now, here's the problem, how do you support that?
Right now the Model type is a simple record with two fields:
type Model =
    internal {
        Constraints : IConstraint list
        Objectives : IObjective list
    }

I can think of at least two approaches.
Brute Force
Change the Constraints field to be an indexed collection and have the index be the Constraint Name. Then add a function: Model.updateConstraint which would change the value the index is bound to and return a new Model. That's simple but here's a big problem, how do you make it efficient to update the underlying model in the Solver with the updated constraint? Do you you just have to build an entirely new model? If you want to incrementally change it, how do you keep track of what changed since you last solved it? Technically that would work but it would be a poor experience and unusable in the situations I'm thinking about.
Model becomes a diff list
Instead of having the Model type be a record, have it be a list of diffs. The final state of the model is just a fold over the changes to the initial model. Each change that is performed could be provided a version number that is just an incrementing int. I imagine it as something like this:
type ChangeIndex = ChangeIndex of int

type ModelChange =
    | AddObjective of Objective
    | AddConstraint of Constraint

type Model = {
    Name : string
    Changes : (ChangeIndex * ModelChange) list
}

Now when you go so solve a model, the solution you get back includes the model and the underlying Solver Model which would depend on the library.
type Solution = {
    DecisionValues : Map<Decision, float>
    Model : Model
    SolverModel : SolverModel
}

You can look at the first element of Solutuion.Model.Changes to get the last version number. Now, if you update or add constraints to the Model, you can instead call Solver.reSolve
let reSolve settings solution model =
    // The first thing you would do is look for the updates in `model` compared to the version in `solution`
    // and make the appropriate updates to the solver model

This a rough idea and I think it is Solver dependent. I know that CBC, GLOPS, and Gurobi can do this. I'm betting CPLEX can as well. You definitely don't want to use a List to store the changes in the Model type because you will want to traverse up and down the values. I'm not sure if there is an efficient way to do that but I haven't looked.
Also, when building the model you want to start with the initial change and then work forward in time. I'm sure there's a data structure for this. I just don't know if off the to of my head.

Something that I started to formulate in my head is a way to support the iterative workflow of:

Build initial Model
2 Solve Model
Evaluate Solution

If solution good

Done

If not

Update model, return to 2

This would be a really useful way of iteratively exploring a model. Now, here's the problem, how do you support that?
Right now the Model type is a simple record with two fields:
type Model =
    internal {
        Constraints : IConstraint list
        Objectives : IObjective list
    }

I can think of at least two approaches.
Brute Force
Change the Constraints field to be an indexed collection and have the index be the Constraint Name. Then add a function: Model.updateConstraint which would change the value the index is bound to and return a new Model. That's simple but here's a big problem, how do you make it efficient to update the underlying model in the Solver with the updated constraint? Do you you just have to build an entirely new model? If you want to incrementally change it, how do you keep track of what changed since you last solved it? Technically that would work but it would be a poor experience and unusable in the situations I'm thinking about.
Model becomes a diff list
Instead of having the Model type be a record, have it be a list of diffs. The final state of the model is just a fold over the changes to the initial model. Each change that is performed could be provided a version number that is just an incrementing int. I imagine it as something like this:
type ChangeIndex = ChangeIndex of int

type ModelChange =
    | AddObjective of Objective
    | AddConstraint of Constraint

type Model = {
    Name : string
    Changes : (ChangeIndex * ModelChange) list
}

Now when you go so solve a model, the solution you get back includes the model and the underlying Solver Model which would depend on the library.
type Solution = {
    DecisionValues : Map<Decision, float>
    Model : Model
    SolverModel : SolverModel
}

You can look at the first element of Solutuion.Model.Changes to get the last version number. Now, if you update or add constraints to the Model, you can instead call Solver.reSolve
let reSolve settings solution model =
    // The first thing you would do is look for the updates in `model` compared to the version in `solution`
    // and make the appropriate updates to the solver model

This a rough idea and I think it is Solver dependent. I know that CBC, GLOPS, and Gurobi can do this. I'm betting CPLEX can as well. You definitely don't want to use a List to store the changes in the Model type because you will want to traverse up and down the values. I'm not sure if there is an efficient way to do that but I haven't looked.
Also, when building the model you want to start with the initial change and then work forward in time. I'm sure there's a data structure for this. I just don't know if off the to of my head.

I can help with making things efficient including the use of good data structures. You and @smoothdeveloper can focus on converting a change in a Flips model to a change in a solver model for each type of solver.

I can help with making things efficient including the use of good data structures. You and @smoothdeveloper can focus on converting a change in a Flips model to a change in a solver model for each type of solver.

I guess my main concern when it comes to the data structures is that Flips is adheres pretty closely to F# norms so immutability (or the perception of immutability, persistent data structures "cheat") is a key concern I have.
I also think that there should be different function for update* vs add*. An add* assumes that the thing being added was not a part of the model yet. An update* would check that it already existed. The question then becomes, "Do we validate at the point we update or do we wait until we call Solver.reSolve? My preference would be that errors are raised as close to when they occur as reasonable.

I guess my main concern when it comes to the data structures is that Flips is adheres pretty closely to F# norms so immutability (or the perception of immutability, persistent data structures "cheat") is a key concern I have.
I also think that there should be different function for update* vs add*. An add* assumes that the thing being added was not a part of the model yet. An update* would check that it already existed. The question then becomes, "Do we validate at the point we update or do we wait until we call Solver.reSolve? My preference would be that errors are raised as close to when they occur as reasonable.

Part of functional programming is about preferring immutablity over mutablity, but not shunning it completely.  Most of the time, immutablity suffices.  If you have a use case that significantly benefits from mutablity, then it is ok to use it.
I have mixed feelings about separating vs combing add and update.  I feel like separation is the default choice.  Maybe callers want to fail when their function of choice is not possible.  On the other hand, combing them yields an idemponent function, which is a great property for a function to have.  I suspect the mixed feelings result from separation being correct in some cases and combining being correct in others.

Part of functional programming is about preferring immutablity over mutablity, but not shunning it completely.  Most of the time, immutablity suffices.  If you have a use case that significantly benefits from mutablity, then it is ok to use it.
I have mixed feelings about separating vs combing add and update.  I feel like separation is the default choice.  Maybe callers want to fail when their function of choice is not possible.  On the other hand, combing them yields an idemponent function, which is a great property for a function to have.  I suspect the mixed feelings result from separation being correct in some cases and combining being correct in others.

I suspect the mixed feelings result from separation being correct in some cases and combining being correct in others.

I too like the idea of having an idempotent function but I also think a lot about users making unintended mistakes and the hours of debugging. If you only have add*, you will never get an error when you are trying to update an existing constraint. That could be really dangerous because the math will likely still work. As a user, I would rather fail early.
Also, conceptually "adding" a constraint to actually update a constraint feels odd. I'd almost rather have a different word, like set, which suggests either adding or updating.

I suspect the mixed feelings result from separation being correct in some cases and combining being correct in others.

I too like the idea of having an idempotent function but I also think a lot about users making unintended mistakes and the hours of debugging. If you only have add*, you will never get an error when you are trying to update an existing constraint. That could be really dangerous because the math will likely still work. As a user, I would rather fail early.
Also, conceptually "adding" a constraint to actually update a constraint feels odd. I'd almost rather have a different word, like set, which suggests either adding or updating.

@matthewcrews wrt to updating a model with different constraints, I think we should defer a bit on the solver agnostic API for those scenarios, until we play more with the underlying solvers.
I kind of remember I was looking into this in context of CPLEX, few excerpts with relevant conditionals as to update values that have been fed already to an instance:
https://github.com/fslaborg/flips/blob/0275069059435745b52ff5173f5ad3802bf4b376/Flips.Solver.Cplex/CplexSolver.fs#L66-L76
https://github.com/fslaborg/flips/blob/0275069059435745b52ff5173f5ad3802bf4b376/Flips.Solver.Cplex/CplexSolver.fs#L136-L148
https://github.com/fslaborg/flips/blob/0275069059435745b52ff5173f5ad3802bf4b376/Flips.Solver.Cplex/CplexSolver.fs#L19-L29
We can expect each solver to have their idiosyncrasies (or even idioties 🙂) and trying to tackle those concerns at the Flips main API level upfront is going to be untenable if we haven't played more with the backend implementations and came back with a good summary of the issues faced, and solid way to handle it even without Flips (HasDoNotReuseState in code above would be sane default with the rest remaining largely "undefined behaviour" for now).
Those are the areas where we will hit edge cases, hard to figure out bugs, etc. they will be "use at your own risk" for a while, and hence don't need to surface at the main API level, for now, IMO.
Following this, the same would apply for iteration logic, this stuff seems to be highly domain specific and will be hard to figure out, we can rely on documentation to touch on the matter until some great ideas emerge out of real world usages.
All that aside, I do like the idea of "model or solver state is a list of diff", kind of like event sourcing, but I'm not sure it is the best nor simplest we would provide for the main Model object as the default approach, this could be separate "debug audit trail" concern.
We should ideally aim to get Flips 3 with simplest split of solver backend implementation in the packaging and defining the few interfaces/asbstractions, tailored only at retaining the simple API for simple use cases, while having few escape hatches to handle with solver backend in proprietary fashion for advanced use case (see the cplex callback stuff I was experimenting a bit with).
And then learn from that and users feedback to extend the use case footprint in an even later version of the library.

I'm closing this as there is now a Discussions area for this.


Hardening of Kura Camel (better logging, extra tests, etc)

need help for this stuff ?

Actually it is done :) .


pytorch 2.0.0 issue?

Error running process: G:\stable-diffusion-webui\extensions\sd-dynamic-prompts\scripts\dynamic_prompting.py
Traceback (most recent call last):
File "G:\stable-diffusion-webui\modules\scripts.py", line 417, in process
script.process(p, *script_args)
File "G:\stable-diffusion-webui\extensions\sd-dynamic-prompts\sd_dynamic_prompts\dynamic_prompting.py", line 400, in process
# is only available in AUTOMATIC1111 1.3.0+, but might not be in forks.
AttributeError: 'StableDiffusionProcessingTxt2Img' object has no attribute 'hr_prompt'

Wrong repo lol. This is dynamic thresholding, that error is dynamic prompting.


CVE-2024-22262: spring-web is vunerable

Upgrading SpringBoot to 3.2.5 will bump spring-web to 6.1.6 (and CVE will be solved)


UPGRADE FAILED error while updating values.yaml

I want to update the Prometheus alerts by updating the values.yaml using helm. But I am not able to do that because of the following error. I used to update the values.yaml file using the same helm command earlier, but now it doesn’t seem to work. I am getting the same error even when I try to redeploy the previous version of values.yaml. (the one that is currently deployed)
Command :
helm upgrade --install loki grafana/loki-stack --namespace monitoring --values values.yaml
Error:
UPGRADE FAILED: rendered manifests contain a resource that already exists. Unable to continue with update: Role "" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: missing key "meta.helm.sh/release-name": must be set to ""; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "".
I did see some solutions about deleting and redeploying the resources, but that isn’t an option for me because I can’t lose all the Prometheus monitoring data.
Output of helm version:
version.BuildInfo{Version:"v3.7.1", GitCommit:"1d11fcb5d3f3bf00dbe6fe31b8412839a96b3dc4", GitTreeState:"clean", GoVersion:"go1.16.9"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.7", GitCommit:"1dd5338295409edcfff11505e7bb246f0d325d15", GitTreeState:"clean", BuildDate:"2021-01-13T13:23:52Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"windows/amd64"} Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.2", GitCommit:"881d4a5a3c0f4036c714cfb601b377c4c72de543", GitTreeState:"clean", BuildDate:"2021-10-21T05:13:01Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"linux/amd64"}

The error occurs because the chart is attempting to override ownership of an existing resource in your chart. Helm takes a defensive approach: if the chart defines a resource that already exists, it returns an error asking the user to either remove the object in question or make changes to their chart (or its values) so that it will not clash with other objects.
In other words, you are asking Helm to install something that already exists in your cluster. Helm does not support that operation.

Thanks @bacongobbler .
I actually downgraded helm to 3.2.1 and that resolved the issue for me.

The error came back the next time I tried the same command.

In other words, you are asking Helm to install something that already exists in your cluster. Helm does not support that operation.

I thought this command upgraded the current values.yaml file and the --install part only creates the resource if it isn't there.
How do you suggest I make the update then?

Can you please provide the chart, or an example chart that can reproduce the situation?


Emails not being returned from Twitter even after app is whitelisted for emails.

I am not sure if this is a coding problem on my end or a bug with React Native Lock:
http://stackoverflow.com/questions/37999972/twitter-whitelisted-my-application-so-i-can-retrieve-user-email-but-still-not-g

Related rule:  https://github.com/auth0/rules/blob/master/rules/get-twitter-email.md
request({     url: url + '?include_email=true',     headers: {       'Authorization': 'OAuth ' + auth     }   }, function(err, resp, body) {     if (err || resp.statusCode !== 200) {       return callback(new Error('Error retrieving email from twitter: ' + body || err));     }     var result;     try {       result = JSON.parse(body);     } catch (e) {       return callback(new Error('Invalid JSON returned by Twitter'));     }     if (!result.email) {       // Might not want to fail in this case       return callback(new Error('Twitter did not return an email address'));     } else {       user.email = result.email;       return callback(null, user, context);     }   });
Does React Native Lock support the url + '?include_email=true' query string?

@sbefort seems to me that it's outside the scope of this lib. Please go to https://support.auth0.com to get better support since we only handle issues for this library not the auth0 platform

It is a problem with the library.  Auth0 supports it but this library does not.


feature: Parameterized circuit example

Is your feature request related to a problem? Please describe.
amazon-braket-sdk-python supports parameterizing circuits but there is no example for how to use the feature.
Describe the solution you'd like
A notebook that shows how and when to use parameterized circuits.
Describe alternatives you've considered
Updating documentation in the Braket SDK
Implementation Checklist (if applicable)
N/A
Additional context
N/A

@wrasmuss we do have an example of how to use parametrized circuits here: https://github.com/aws/amazon-braket-examples/blob/main/examples/hybrid_quantum_algorithms/VQE_Chemistry/VQE_chemistry_braket.ipynb. Would it help if we made an example under the braket_features folder instead? Thanks!

Searching this repo for FreeParameter doesn't seem to yield any hits. Maybe I'm doing something wrong. Parameter gets a lot of hits but it's too many to sort through. Having a notebook under features specifically for parameterized circuits might help users find the feature, but maybe we could address the feature through helping users find the existing example via keywords or something.

@wrasmuss A more reliable way to search is to clone the repository and search with grep from a console. So in this case you could do something like this from a terminal:
$ git clone https://github.com/aws/amazon-braket-examples.git
Cloning into 'amazon-braket-examples'...
remote: Enumerating objects: 2473, done.
remote: Counting objects: 100% (277/277), done.
remote: Compressing objects: 100% (193/193), done.
remote: Total 2473 (delta 103), reused 240 (delta 82), pack-reused 2196
Receiving objects: 100% (2473/2473), 57.50 MiB | 11.20 MiB/s, done.
Resolving deltas: 100% (1331/1331), done.
$ grep -r FreeParameter amazon-braket-examples/*
amazon-braket-examples/examples/hybrid_quantum_algorithms/VQE_Chemistry/VQE_chemistry_braket.ipynb:    "from braket.circuits import Circuit, FreeParameter, observables\n",

That said it's a good suggestion that this feature (and similar small features) should be easier to discover by way of examples and/or our other documentation, such as the developer guide.

Hasn't this been addressed by AG launch?

There are several examples that use FreeParameters, including the AG example; closing.


CDS JPA server example

This pull request includes an example JPA server that showcases the CDS capabilities of the cql-ruler. There is an issue that is prohibiting the resolution of cds hooks requests. Once that is fixed I will issue another PR with tests for that.

Changes Unknown when pulling f34ec0e811785ffae1773cddd326c8767bbb7580 on c-schuler:master into ** on jamesagnew:master**.

Hi Chris,
This is super cool. I'm merging it now. Note that I'll probably move it into the example-projects/ directory as I'm trying to slowly consolidate examples in there, but I'll do that after merging.


Obsolete version of NPM causing installation problems

Need to change the installer script to install an up to date NPM.

Fixed, installer.sh now installing newest available NPM.


Override dset version to resolve security vulnerability

Resolves https://github.com/evidence-dev/evidence/security/dependabot/163

Branch name is incorrect, opening a new PR


(TWILL-229) Default to use logback_template.xml to configure logger, …

…unless overridden by user

Changes LGTM, may I ask where do we set the logback if it is overriden by user?

For AM, currently it is not settable. For Runnable containers, user can add as resources / localize a logback.xml file and specify it in the classpath.

I see. LGTM


A redundant stemcell record after running "bosh upload-stemcell --fix"

There is a redundant stemcell record  after running bosh upload-stemcell --fix, I think there should be only one record shown in bosh vms. We used bosh release 267.2.
Name                                     Version    OS             CPI               CID
bosh-bluemix-xen-ubuntu-xenial-go_agent  97.3.1*    ubuntu-xenial  -                 1997987
~                                        97.3.1*    ubuntu-xenial  softlayer_ng      1997987

Hey @mattcui,
This happens when you have added a CPI config after previously uploading a stemcell to a director without a CPI config.
When a director does not have a CPI config, it's default cpi is "". After uploading a CPI config, the stemcell will get associated with the matching CPI in the config, which in this case is softlayer_ng. One thing you can do to avoid this is to have the following migrated_from: block in your CPI config for the softlayer_ng CPI:
- name: sotflayer_ng
  type: softlayer
  migrated_from:
  - name: ""

Any subsequent uploads will correctly detect any assets previously associated with the default CPI of "".
At this point in time, we don't consider this behavior a bug. Please let us know if you have any other questions.
Best,
@jfmyers9 && @GarfieldIsAPhilosopher, CF BOSH

@jfmyers9 We tried your approach, seems it didn't do anything after run --fix command, there is no change, we expect softlayer-legacy can be set there as the CPI and only one record for the stemcell.
Name                                     Version     OS             CPI               CID
bosh-bluemix-xen-ubuntu-trusty-go_agent  3468.17.2*  ubuntu-trusty  -                 1840873

bosh upload-stemcell --fix is used for reuploading the bits of the stemcell in the IAAS/blobstore, not for updating it's database representation. Unfortunately, if you have already uploaded the stemcell without the CPI config, there is not currently a way to get the previous stemcell to show up with the updated CPI name.
Using migrated_from: will prevent there from being duplicate stemcell references. This also is only a temporary issue when migrating to a CPI config, as all subsequent stemcells that are uploaded will reference the correct CPI.

Thanks, closing this issue


Store transformed XML

Store transformed XML in version data directory
also copy original article to known path

Once this is in shall we re-trigger the import of everything so that we have the transformed xml available for those already imported?

Once this is in shall we re-trigger the import of everything so that we have the transformed xml available for those already imported?

That would be useful, yes.


Update Dockerfile

Removed the outdated rsync downgrade which is no longer available.

Closing in favor of https://github.com/stackhpc/kayobe-automation/pull/48


DBZ-2302: Allow OffsetCommitPolicy to be initiated with Properties object

In order to fix the issue that is reported in DBZ-2302, the EmbeddedEngine should initiate the OffsetCommitPolicy with Properties type being provided instead of Configuration type in order to keep the debezium-api light without depending on debezium-core (if I understood it correctly) for Configuration type.
Sorry in advance @gunnarmorling @jpechane if I have missed something, is been sometime since I contributed to Debezium :).
P/S: Also I have tested with camel-debezium-* integration tests that we have there

@omarsmak Nice job, thanks!


Improve progress indicator

As the execution takes long it would help help a lot of there was some progress activity.

Pull request #34


chore: Add multipart payload support for admin settings

@sharat87 Can you please check the failing test here? This is a legitimate failure.

@trishaanand, can you review this when you get a chance please? Need these changes soon for branding. Thanks.


Usability issue with Sync constraint requirement.

The fact that all the constructor methods in Slf4jLogger require a Sync instance is very detrimental to the usage of this library -- especially when considering that the macro call needs to live inside every class to produce the desired class name in the log lines. This effectively means all classes that log need the Sync constraint.
I'm not sure there is an easy solution here, though :/

There is a solution, we can either incapsulate Logger creation ability or delay ability.
The first option is kind of obvious, here is the simplified example:
trait Slf4jLoggers[F[_]] {
 def make: Slf4jLogger[F]
}
object Slf4jLoggers {
 implicit def fromSync[F[_]: Sync]: Slf4jLoggers[F] = //... delay unsafe loggers creation
}

class MyService[F[_]: Slf4jLoggers] {
 val logger: Logger[F] = Slf4jLogger.getForClassOrSomethingElse
}

But this would require us to rework existing code, make some tough design decisions and is not what I would call an easy solution.
The second option can be seen in some libraries already, e.g. tofu: it's the Delay typeclass, which is "weaker" than Sync. Its instance can be derived directly from the Sync instance, but not the other way around.
Then the logger creation would require only Delay in scope, so the code would be less detrimental.
@danicheg is it possible to use tofu.Delay here or even simply copy-paste it into the project (just like with the laconic syntax)?
Or perhaps the factory option looks more pleasant, WDYT?

I believe this issue can be closed as the #629 was released.


Unmaintained server?

hi, after installing magento on php 7, all patches are green (according to: https://www.magereport.com )
but "Unmaintained server?" status shows "unknown"
and magento-check.php tool shows:
You need PHP 5.2.0 (or greater)'; } else { $pass .='
You have PHP 5.2.0 (or greater)
'; } if(!ini_get('safe_mode')) { $pass .='
Safe Mode is off
'; preg_match('/[0-9].[0-9]+.[0-9]+/', shell_exec('mysql -V'), $version); if(version_compare($version[0], '4.1.20', '<')) { $fail .= '
You need MySQL 4.1.20 (or greater)
'; } else { $pass .='
You have MySQL 4.1.20 (or greater)
'; } } else { $fail .= '
Safe Mode is on
'; } foreach($extensions as $extension) { if(!extension_loaded($extension)) { $fail .= '
You are missing the '.$extension.' extension
'; } else{ $pass .= '
You have the '.$extension.' extension
'; } } if($fail) { echo '
Your server does not meet the following requirements in order to install Magento.'; echo '
The following requirements failed, please contact your hosting provider in order to receive assistance with meeting the system requirements for Magento:'; echo '
'.$fail.'

'; echo 'The following requirements were successfully met:'; echo '
'.$pass.'

'; } else { echo '
Congratulations! Your server meets the requirements for Magento.
'; echo '
'.$pass.'

'; } } ?>
is this normal? :/

Yes, it's normal, as these tools don't recognize that you can run M 1 on PHP 7 :-)

I run M1 on PHP7 but magereport.com does not give unmaintained server when
i scan. You can contact byte.nl or leave a suggestion on the magereport.com
site.


submit_qubo daily integration test fix

Updates qpu -> simulator

the test is failing due to a new mypy release. simple fix is to change line 488 in qubit_gates to:
            return sum(cirq.num_qubits(g) for g in self.component_gates[:first_instance])


Fix DRPC not waiting for the VRG deletion confirmation

Bug 2074567 - DRPC does not wait for the VRG deletion confirmation

So deleting DRPC means the App is also deleted, PVCs will go to deleted state and we should delete the VRG in all Managed clusters no matter in what state they are at.


Update task table_transformer

Needs to be fixed for task list, show, show-run, list-runs

Waiting on review from @sajayantony @SteveLasker .


Add support for checking if a list of files have the expected owner

PR Type
enhancement

Description

Added a new check class FilesOwnedByUser to verify if a list of files are owned by a specified user.
Implemented get_file_owner function in file_utils.py to retrieve the owner of a file using os.stat and getpwuid.
Enhanced the daktari module to support file ownership verification, improving its utility for file management tasks.

Changes walkthrough 📝
Relevant filesEnhancement

files.pyAdd file ownership check functionality

daktari/checks/files.py
Added a new class FilesOwnedByUser to check file ownership.  Implemented a method to verify if files are owned by a specific user.  Utilized expanduser to handle user directory paths.

+19/-1

file_utils.pyImplement function to get file owner

daktari/file_utils.py
Introduced get_file_owner function to retrieve file owner.  Used os.stat and getpwuid to determine file ownership.

+6/-0

💡 PR-Agent usage: Comment /help "your question" on any pull request to receive relevant information

The Enhancement suggestions from the codiumai-pr-agent-pro bot dont apply in this case, as the handling is sufficient for when the file is missing during file check, and in the other case it would throw an exception regardless


Testing of Zeus failed

Running go test -bench=. -timeout=20m but failed:
--- FAIL: TestRouters (2.72s)
	routers_test.go:78: Zeus in API Static: 301 - Moved Permanently.

		; expected GET /articles/
	routers_test.go:78: Zeus in API Static: 301 - Moved Permanently.

		; expected GET /articles/wiki/
	routers_test.go:78: Zeus in API Static: 301 - Moved Permanently.

		; expected GET /codewalk/
	routers_test.go:78: Zeus in API Static: 301 - Moved Permanently.

		; expected GET /devel/
	routers_test.go:78: Zeus in API Static: 301 - Moved Permanently.

		; expected GET /gopher/
	routers_test.go:78: Zeus in API Static: 301 - Moved Permanently.

		; expected GET /gopher/pencil/
	routers_test.go:78: Zeus in API Static: 301 - Moved Permanently.

		; expected GET /play/
	routers_test.go:78: Zeus in API Static: 301 - Moved Permanently.

		; expected GET /progs/

I'd like to make a PR, but I am not familiar with Zeus.

It has to be fixed in the router: https://github.com/daryl/zeus/issues/2
If they won't fix it before the next run, I'll simple kick Zeus out.
You can still run the benchmark with go test -run=None -bench=. -timeout=20m. This way the verification phase is skipped and only the benchmarks are run. But ignore the Zeus result then.

Thanks!


Use providers in the VM factories to respect the dep di semantics

Task/Issue URL: https://app.asana.com/0/30173902528854/1200098175084894/f
Tech Design URL:
CC:
Description:
https://github.com/duckduckgo/Android/pull/1123 introduced a bug that was detected by our pixels.

That pull request delegated the creation of the view models (VMs) to its own factory
The VM factories are singleton -- as they should be
The VM factories create the VMs and inject their dependencies
Because the VM factories are singleton that effectively makes all VM dependencies singleton. Regardless of whether they are actually declare as such or not
This is not desired, VM factories thouls be singleton, but it should respect the di semantics of its deps

This PR makes all the factories to provide providers of the dependencies, rather than the actual instance. So that they respect how the instances declare themselves when injected, ie. singleton or multiple instances.
In particular, the effects can be seen with the fw_ pixels. They are fired multiple times (one per fragment) when they should fire only once.
Steps to test this PR:

App compiles

install/upgrade the app from this branch

use the SERP to perform searches

form the SERP, open several tabs

add/remove bookmarks

add/remove fireproof sites

navigate to settings screen

use fire button

clear app data and go through onboarding UX

for all above, verify app works as expected

install/upgrade from this branch

open several tabs and ensure they are active

ensure Ask When Signing In is enabled inside settings -> fireproof sites

open a new tab and log into facebook.com (or any other login you may want)

verify the dialog to fireproof the site appears

navigate to any other of the active tabs

verify no dialog appears

verify m_fw_xx are only shown once

Internal references:
Software Engineering Expectations
Technical Design Template

BTW, please, remember to create a task in Asana for this task and add it to the release board 👍

I think providers are missing in WelcomePageViewModelFactory, could it be?
That factory is not part of the ViewModelFactoryPlugins. WelcomePage fragment uses that factory instead of the generic app ViewModelFactory.
We should move it there, will do in a separate task/PR

BTW, please, remember to create a task in Asana for this task and add it to the release board 👍 (and add it to the description)

Will do


InputMap already has action "left_mouse_button"

This is really a small nitpick: when launching the main scene (visualisation.tscn), godot complains:
E 0:00:00.705   add_action: InputMap already has action "left_mouse_button".
  <C++ Error>   Condition "input_map.has(p_action)" is true.
  <C++ Source>  core/input_map.cpp:89 @ add_action()
  <Stack Trace> gridmap.gd:14 @ _ready()

With my limited godot knowledge, I think this happen because we define "left_mouse_button" twice:

Once, as the error says, in gridmap.gd, line 14;
And also in the project's settings, in the InputMap panel.

Removing either one fixes the message (and all scenes keep working), I just don't know which one should be kept.

Solved in 237a13af11b3257b10353c6fe77eee17e10728ec


rename: pretty print exception classes

Renamed exception class is not pretty printed (expected keyword = upper case, vars = lower). Am I missing some config?

https://rules.abaplint.org/keyword_case/, set "ignoreExceptions": false,
note there is a similar setting in https://rules.abaplint.org/indentation/

👍


Add instructions to add a node to the Developer Quickstart

The Besu equivalent issue can be found here:
https://github.com/hyperledger/besu-docs/issues/836
Add similar instruction in GoQuorum

Documented in https://github.com/ConsenSys/doc.goquorum/pull/150


Building on Linux (Debian stretch) failed

when running ruby build-linux.rb I get this error msg:
Looking For pkg config modules
-- Checking for module 'ntk'
--   No package 'ntk' found
-- Checking for module 'ntk_images'
--   No package 'ntk_images' found
-- Checking for module 'fftw3'
--   No package 'fftw3' found
CMake Error at rtosc/cmake/ColorMessage.cmake:53 (_message):
  A required package was not found
Call Stack (most recent call first):
  /usr/share/cmake-3.7/Modules/FindPkgConfig.cmake:415 (message)
  /usr/share/cmake-3.7/Modules/FindPkgConfig.cmake:588 (_pkg_check_modules_internal)
  src/CMakeLists.txt:33 (pkg_check_modules)

-- Configuring incomplete, errors occurred!
See also "/home/user/synth/zyn-fusion-build/build-zynaddsubfx-demo/CMakeFiles/CMakeOutput.log".
See also "/home/user/synth/zyn-fusion-build/build-zynaddsubfx-demo/CMakeFiles/CMakeError.log".
ERROR: 'cmake ../zynaddsubfx/ -DGuiModule=zest -DDemoMode=true -DCMAKE_INSTALL_PREFIX=/usr' failed

CMakeError.log
CMakeOutput.log

On 06-09, merspieler wrote:

-- Checking for module 'fftw3'
--   No package 'fftw3' found
CMake Error at rtosc/cmake/ColorMessage.cmake:53 (_message):
A required package was not found

If you're building the linux version, please ensure build dependencies
are installed includeing fftw3.

I've installed fftw3 via apt and it shows me that version 3.3.5-3 is installed. While installing apt said it's choosing libfftw3-3 instead of fftw3... the build still fails

I've found the problem with fftw3... i needed to install the -dev package.
A dependency list would be good to have...

https://github.com/zynaddsubfx/zyn-fusion-build/wiki/Building-on-Linux  should cover that unless I'm mistaken


Make the Y axis numbers strict to integer only

At Dashboard , there is a profile views chart where we are showing the user profile views of their public profile page
But on the chart , there are some non - integers like decimals that can also be seen , that doesn't make sense as the user can be interger only
Image for reference

Hi @harsimran-d
Would you love to start from here ?

on it

i have added the fix to the same Linting and formatting PR #7
This fix was simple
just setting the flag allowDecimals={false} on the <YAxis> component

Okay . Thanks , will review and merge it soon


Error while create table shop

Describe the bug
I keep getting this error when install s-cart. please assist

What's version?
Vào Th 5, 8 thg 7, 2021 vào lúc 12:26 sbiwaichoon <
@.***> đã viết:

Describe the bug
I keep getting this error when install s-cart. please assist
[image: Capture]
https://user-images.githubusercontent.com/42166985/124867121-1442cf80-dff0-11eb-9148-daf3d29c1eff.PNG
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/s-cart/s-cart/issues/84, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADDT5M4PVIRAFROIUEXONMLTWUZJNANCNFSM4777QQAA
.


解析xls的时候 格式保护之后 size过大 内存溢出

Please attach sample file.

对新建的xls表格进行如下操作后 https://jingyan.baidu.com/article/597035521917ee8fc00740d0.html
文件workbook.go中 235行
if phonetic_size > 0 {
var bts []byte
bts = make([]byte, phonetic_size)
err = binary.Read(buf, binary.LittleEndian, bts)
if err == io.EOF {
w.continue_apsb = phonetic_size
}
}
这个phonetic_size 值会非常大  make([]byte, phonetic_size) 会直接崩掉。

try this fork: https://github.com/sergeilem/xls

试试这个分支：https：//github.com/sergeilem/xls

您好，试了您的分支，还是出现了 内存溢出 @sergeilem
d1ee3514608b4fb49456e73d43245bc9.zip

我也遇到类似的问题
oom.zip

解决方案：https://github.com/shakinm/xlsReader

when xls files are encrypted, there will be a FilePass token (0x2f)
ref: https://stackoverflow.com/questions/25422599/parse-xls-file-with-protected-protected-workbook
we can stop parsing while reading in this token as a work around solution.
in workbook.go
 44 func (w *WorkBook) Parse(buf io.ReadSeeker) {  45         b := new(bof)  46         bof_pre := new(bof)  47         // buf := bytes.NewReader(bts)  48         offset := 0  49         for {  50                 if err := binary.Read(buf, binary.LittleEndian, b); err == nil {  51                         // stop parsing if this file is encrypted  52                         if b.Id == 0x2f {   53                                 break  54                         }  55                         bof_pre, b, offset = w.parseBof(buf, b, bof_pre, offset)  56                 } else {  57                         break  58                 }  59         }  60 }

@pcjeff thanks for this workaround! I can still open and see the .xls file contents in LibreOffice as well as edit it, but there's a padlock icon on the sheet tab. I'm not sure how exactly it "protects" the sheet. In my case this bug caused a huge allocation crashing my program with OOM in the end. I'd love to have support for encrypted/protected sheets but until then just skipping such files is acceptable.


Hi, I have a problem with this awesome library in my project.

We have a expand collapse element at the top of the page and then we have implemented leader line below it  in a container. so when I am expanding the element the the leader line overlaps with my above element when expanded and is not responsive.
Could you please help me out. I am stuck.

Hi @shahnawaz09, thank you for the comment.
Do you mean that the leader line doesn't be fixed when the elements are moved?
If so, you have to call position method when the layout is changed.

Hi @shahnawaz09, thank you for the comment.
Do you mean that the leader line doesn't be fixed when the elements are moved?
If so, you have to call position method when the layout is changed.

Yes @anseki  the leader lines are not fixed when I expand the above element. How to call position method ?

Yes @anseki  the leader lines are not fixed when I expand the above element. How to call position method ?

It gets overlapped with my above element when I expand the element.

It gets overlapped with my above element when I expand the element.

var line = new LeaderLine(
document.getElementById('d1'), document.getElementById('d2'),
{
positionByWindowResize: false,
dash: { len: 2, gap: 2 },
startSocketGravity: [0, -2],
path: 'grid',
startSocket: 'top',
endSocket: 'top',
color: '#ffffff',
size: 0.5,
endPlug: 'disc',
endPlugSize: 2.5,
  }
);
document.getElementById('testContainerNew').addEventListener('click', function () {
  line.position();
  console.log("clicked");
});

Please refer mt above code. Its an angular application . Still not working. Could you please help me out.

var line = new LeaderLine(
document.getElementById('d1'), document.getElementById('d2'),
{
positionByWindowResize: false,
dash: { len: 2, gap: 2 },
startSocketGravity: [0, -2],
path: 'grid',
startSocket: 'top',
endSocket: 'top',
color: '#ffffff',
size: 0.5,
endPlug: 'disc',
endPlugSize: 2.5,
  }
);
document.getElementById('testContainerNew').addEventListener('click', function () {
  line.position();
  console.log("clicked");
});

Please refer mt above code. Its an angular application . Still not working. Could you please help me out.

"testContainerNew" is my expand/collapse element.

"testContainerNew" is my expand/collapse element.

Do you mean that the position method didn't work?

Do you mean that the position method didn't work?

For example: https://jsfiddle.net/37duypmo/
BTW, the positionByWindowResize in your code is incorrect.
See document: https://anseki.github.io/leader-line/#position

For example: https://jsfiddle.net/37duypmo/
BTW, the positionByWindowResize in your code is incorrect.
See document: https://anseki.github.io/leader-line/#position

No reply came, then this abandoned issue is closed.

Great help @anseki .. issue got resolved

but when we animate with css keyframes content of a box on page load. then how to call leader line position method.


[release-1.10] server/container_create: error out if capability is unknown

Signed-off-by: Antonio Murdaca<EMAIL_ADDRESS>
- What I did
- How I did it
- How to verify it
- Description for the changelog

/test all