Deprecation warnings

When using this template with Typst 0.12, Typst gives me 2 deprecation warnings from for the template. These are:

locate with callback function is deprecated
Calling counter.final with a location is deprecated

The project works perfectly fine, without any troubles, but this should probably be replaced at some point. Typst recommends using context or removing the location argument.
I would fix this myself, however, I have no knowledge on how to work with the template source.

This deprecation warning has been fixed in #12, but I haven't made a new release yet. I will make a new release tomorrow. I'll let you know here when it's published.

A new version has been released. Until typst/packages#1189 has been merged, you can follow the alternative installation instructions in the README.


Aspire Authorization: Microsoft Entra External ID

Please provide us with the following information:

Losing the socket connection.
I followed:
https://learn.microsoft.com/en-us/training/modules/create-aspire-applications/learn-how-create-new-aspire-application
How to add Authorization with  External ID?
Overview - External ID in external tenants - Microsoft Entra External ID | Microsoft Learnhttps://learn.microsoft.com/en-us/entra/external-id/customers/overview-customers-ciam
Secure your apps using External ID in an external tenant
This issue is a: (mark with an x)

[ X] bug report -> please search issues before submitting
[ ] documentation issue or request
[ ] regression (a behavior that used to work and stopped in a new release)

Issue description
When Microsoft Entra External ID Authorization is added the demo app loses interactivity (Counter) is not working
and there is a browser message the socket loses connection.
Expected behavior [What you expected to happen.]
Adding Microsoft supported Authorization should be working.
Actual behavior [What actually happened.]
Doesn't works at all

Additional context
This happens when uploaded to Azure.

Possibly related #812

@aitrailblazer fix for this issue has been rolled out. Please let us know if you still encounter this. Thanks!

Please refer to a link how to do that?

I'm getting the same error, there is no interactivity on the Counter and WebSocket Error

@aitrailblazer is this related to accessing the Aspire dashboard? Can you please provide steps you took to enable Aspire dashboard and access it?

This is related to Aspire deployment to container and impossible to use Microsoft Entra External ID. Can Aspire be deployed as Web App?

This does not seem like a container apps issue. Can you please post here and link this issue? @davidfowl @drewnoakes @joperezr

I posted it there too
https://github.com/dotnet/aspire/issues/5579


feat(build, version): add version and commit to builds

Version and GitCommit is now added as part of NDM build. This will enable the binaries to log commit from which the build was generated and also the version of NDM.
By default ci will be the version used. For releases and RC builds the tags will be used as version.

Codecov Report

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

@@          Coverage Diff           @@
##           master    #338   +/-   ##
======================================
  Coverage    52.6%   52.6%
======================================
  Files          50      50
  Lines        2416    2416
======================================
  Hits         1271    1271
  Misses       1044    1044
  Partials      101     101

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 32fc2d2...aba679a. Read the comment docs.


⚠ Bofrost.de has degraded performance

In 5b13cc2, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1780 ms

Resolved: Bofrost.de performance has improved in ab5270d after 8 minutes.


Support for $date, generalized pre- and post-processing, comprehensive management of vector coercion

Along the way to implementing $date consistently, this PR refactors the pre- and post-processing to and from the API calls in a way that visits the whole payloads/responses and ensures every method passes through it.
Tests updated accordingly.
Closes #163 .

The tests now fail due to the API beta7 being in prod (#169 fixes that and should probably be first merged and then brought to this PR for an orderly test-passing flow)

Thank you, @cbornet , all accepted


model checkpoint

Hi, thanks for your work, is there any shareable model checkpoint.

Hello, sorry we don't have a shareable checkpoint.


Outreach to another TinyGo feature author

Hello @rchaganti! 👋
I noticed your https://github.com/rchaganti/vsc-devcontainer-features/tree/main/src/tinygo TinyGo installer feature! I figured you might be interested in this project. 😊

Nice! This is a non-sudo one. Is there a way we can merge both?

sounds good! 👍
if you're "is there a way we can merge both?" is asking "open to collaborating?" then the answer is YES!
if asking "how logistically does the merge look?" it looks like @lee-orr did the same thing (deprecated a tinygo feature) by just putting a notice in the readme and removing the code. https://github.com/lee-orr/rusty-dev-containers/commit/35910a9996f8e6778028a568ad68c59af2982f6a


active heat vent textures seem bugged

this seems like it may be caused by a missing .mcmeta file for the texture

this is on terrafirmagreg v0.7.12 on minecraft 1.20.1 with the resource pack version 0.7 - modern


WIP: Deploy from repo

Do we plan to merge this before / for v0.8 or are we going to wait?

I was hoping to merge it before but I need to fix the apt repo to be split
by stable/unstable.
On Feb 28, 2015 5:20 AM, "Tomaz Muraus"<EMAIL_ADDRESS>wrote:

Do we plan to merge this before / for v0.8 or are we going to wait?
—
Reply to this email directly or view it on GitHub
https://github.com/StackStorm/st2/pull/1151#issuecomment-76525820.

Super old PR! Re-open if it's still applicable.


Limit auto roll/pitch rates

This change limits the MC attitude controller roll and pitch rate setpoints to the values specified by the MC acro_rate_max parameters. The copter should behave the same in roll/pitch in manual and auto modes.
Ths PR adds two new parameters for MC attitude controller rate limiting;
In addition to MC_YAWRATE_MAX, there are: MC_PITCHRATE_MAX and MC_ROLLRATE_MAX
The default value for each is 120 deg/sec.
Note that MC "ACRO" mode bypasses the attitude controller, so these limits do not apply to that mode.

@kd0aij Perhaps rename these parameters to reflect that they affect other things than just Acro mode? I think this is important for clarity.
eg.
MC_P_RATE_MAX
MC_R_RATE_MAX
MC_Y_RATE_MAX

I agree that a rename makes sense. Right now we're still in "get it to work" mode, we can lock in to "don't break mode" once everything has been finalized.

Agreed on the suggestion for renaming. Especially since we don't seem to have an "acro" mode anyway.
@Zefz BTW, I think this would be a critical safety enhancement, if we can show that the lack of it caused your crash.

It would be hard for me to reproduce the error that caused the crash, but I can try flying this branch next time just in case ;)

I just realized that the "acro" in mc_att_control_main refers to manual rate control vs. manual control of angle...
But the existence of this mode is not apparent to me here: https://pixhawk.org/users/system_modes?s[]=flight&s[]=modes
Did I miss it, and is it an actual design intent to not support this mode?

Question: when doing the rename of acro rate parameters, I realized that we already had MC_YAWRATE_MAX, which will now be redundant to MC_Y_RATE_MAX, if we don't have separate sets of parameters for "acro" vs. auto. I vote we replace MC_YAWRATE_MAX parameter with MC_Y_RATE_MAX.

Acro rates and rate limits are strictly not the same thing. ACRO max rates is what the user can command as maximum (its the scaling of his 100% stick to a rate). The roll / pitch rate limit is an entirely different thing. It doesn't depend on the limitations of the user (how aggressive he likes to fly), but what the system is capable of.

Which means we'd need two sets of parameters; unless the intent is not to support manual acro mode. Also, I was of the opinion that the acro mode flyer wants those limits to be the same as the  limits of the system :)
So back to my first question... Did I miss it, or is it an actual design intent to not support acro mode?

Acro is available, just not widely documented:
https://github.com/PX4/Firmware/blob/master/src/modules/sensors/sensors.cpp#L1986

I guess we want 2 new parameters then, instead of the proposed rename. And I do practice acro mode with my smaller quads, plus I get the impression the FPV racers use acro mode also.

Added new parameters with same default values as yaw rate: 120 dps
Still needs more flight testing

I think this flight log validates roll/pitch rate limiting: https://copy.com/gjRJoOJDmLdXjtI2
(I think it's this one: http://dash.oznet.ch/view/EyeXCDB3oBAmQVE6DCxinP but there's no way I can be sure)
Relevant section of log is where I aborted POSCTL due to erratic behavior:

I don't see why there should be a roll/pitch rate limit because this is essentially what MC_ROLL_P and MC_PITCH_P are there for. They translate an attitude error to a rate, so to "limit" the rate, these should just be reduced.

Motivation is that there have been multiple recent crashes which appear to be due to instability triggered in auto mode by excessive demand for roll/pitch rate. As the plot above hints, the position controller is capable of generating arbitrarily large rate demands given bad estimates of position/velocity. But there are physical limits to achievable angular rates, and reducing P gain does not remove the root cause (either).

@Zefz It seems to me that quality of position control degrades after a minute or so of operation. Is it possible that the position estimator is beginning to diverge?

I have not observed this behaviour so far. I've been flying today and my copter was holding its position just fine (within 1 meter or so). This was even when using the poorer LEA6H gps.

You didn't see any large tilt angles/rates like the ones in my log?
I guess this says I should try a different GPS module

@kd0aij I ran a test today as well hovering the copter until battery was drained. (This was with the better M8 gps). It held position and altitude just fine for about 10 minutes.

Can you post the log?

This is another example of POSCTL calling for max roll/pitch rate with no change in setpoint. 3DR LEA6H GPS

LPOS.x and LPOS.y along with their setpoints:

Hi @kd0aij and @Zefz
We're facing similar interesting posctl issues at the moment. I also think that a rate limit does not fix the root cause, but it could really be useful to help prevent crashes. I'm guessing that the cause for most of these issues is a badly tuned position controller, and I'm also wondering what it will do eventually if rates are limited...
Here's what happened to us this week (first attitude, then rates):

No crash btw, we had a great pilot ;) (to be fair: once back in altctl, it stabilized instantly)
The pilot gave a hard pitch input and let it go. Pitch started to oscillate first, then it flipped (in roll). The autopilot did not command it to roll it seems (roll rate and roll rate SP go into opposite directions). We're not sure why it wasn't able to prevent the flip. One possibility is that because of the already extreme pitch rates, the thrust on the motors was at max already and it just couldn't correct this anymore. (suggestions welcome :))
Here's the complete log: http://dash.oznet.ch/view/6ZgDVpUWa5D34FTckxcwAR

Agreed on the rate limit. One of the first things I did with my own controller was to limit the final PWM deltas on the roll/pitch outputs to a sensible magnitude. That greatly reduced my crash frequency while I was developing the code. This type of clamping is very effective at increasing the stability of a PID controller. We can probably eliminate the risk of crashes due to poor position controller tuning with these clamps, By design, bad GPS should not be able to degrade the stability of attitude control under any circumstances. Perhaps we're missing a lowpass filter somewhere...

We might also be missing a glitch detection in the GPS (@LorenzMeier has mentioned this before) and APM has implemented this as well.
The LEA6H GPS series can suddenly glitch in position and jump a long distance before converging correctly again. If this is the cause, then it should show on GPS.Lat and GPS.Lon using the GlobalPositionProjection processor.

@kd0aij As you can see the rate setpoint are also completely stable:

OK, what I'm seeing is a GPS glitch: same plot as before with Lat/Lon instead of GPS velocity:

GPS glitch is of course not good. But it's also not much different from just pulling on pitch really hard (or give a new offboard setpoint). In any case, the position controller should not be able to command such drastic measures that it leads to a crash.
@kd0aij how does your local position look during your GPS glitch? Just wondering how bad the glitch influenced it.

I don't want to see max roll/pitch rates and +/-30 degree tilt (as the above plots show) when I'm expecting the copter to hold position. Makes the spectators (and this pilot) nervous :) A camera gimbal wouldn't appreciate it much either.

It looks like I was moving the X setpoint slowly towards me (and the flightline) when the vehicle pitched strongly in the opposite direction, then rapidly back towards the pits (considered bad form at most fields). It appears that my reaction was to move the setpoint rapidly away from the flightline while the copter traveled about 4 meters in that direction. But LPOS says the copter moved 5 meters opposite to my command during the 2 seconds immediately following my reaction.
I hope I'm interpreting the log correctly; would much appreciate your analysis.
The log is 17_28_57 here: https://copy.com/wA6akcpmhZOOleZD

To me this looks like the POS_P, VEL_P and ROLL/PITCH_P all need to be tuned down.

@bansiesta
Assuming you meant MPC_XY_P, MPC_XY_VEL_P, MPC_Z_P and MPC_Z_VEL_P, by "POS_" and "VEL_"... I just tried reducing them. No exciting behavior, but also poor setpoint tracking, and unacceptably slow response to the right stick (was forced to go back to manual when actual position error exceeded available space and there was no immediate response to controls).
Could you be a bit more precise about which gains you would reduce, and by how much?
Regarding "ROLL/PITCH" do you mean e.g.  MC_ROLL_P, and/or  MC_ROLLRATE_P by that? I like the way the copter flies in manual mode and both attitude and rate setpoint tracking are good. Decreasing these doesn't sound like the right approach.

@Zefz If you will post the log from that flight with the good LPOS setpoint tracking, along with a description of the copter, I'll be able to see your parameter values and compare my configuration to yours.

@kd0aij I mean MC_ROLL_P and MC_PITCH_P because they translate an attitude error to a needed rate setpoint.

Tuning
We did some experimentation using jMAVSim first to understand how these parameters work and it was very useful. Ramp up XY_VEL_P then give a fast pitch input and watch in go crazy. You can then see how tuning the various params works and it's pretty safe ;)
For our low Kv large prop setup (TBS Long Range) we found that just reducing the XY_VEL_P value from 0.1 to 0.07 and XY_VEL_D from 0.01 to 0.008 was enough to stabilize dangerous increasing oscillations that you could trigger with quick pitch impulses. Obviously the direction and amount will depend on what you are flying. I would start with a low XY_VEL_P value, very low or zero XY_VEL_D then move up P till it starts to oscillate after sharp stick input and slightly then increase D in 0.005 steps.
Tuning should be done using the realtime plot and watching the pitch / pitch sp motion for oscillations.
Rate Limits
In the end I was really surprised by the radical behavior. I had been thinking of a well tuned multirotor being the basis of anything else you do beyond this. So if it is rock solid in manual any additional functionality like POSCTL/Auto/Offboard would never exceed this base behavior. It's OK that it might fly too fast, too slow, track badly but it should never lose control and crash/flip.
Back the point of the PR: if rate limiting can help prevent disaster for now I don't see why we can't do this as at least a temporary safety feature until the underlying position control functionality has been improved (it needs it).

@kd0aij here you can see from top to bottom: X, rate, att, Y, RC

I think your analysis is correct. LPOS.X suddenly changes 4m back to where it came from, it increased attitude in the direction it was already going (67-68), so you naturally steered in the opposite direction which moved the setpoint 3m and caused rates going into the opposite direction as well (68-69)

many thanks @bansiesta @SimonWilks @AndreasAntener
The tuning advice is greatly appreciated and I think I'm beginning to understand things at least a little now.
Using jMAVSim is sound advice; virtual props are a lot easier to replace :) Also, it's reassuring to know which gains you modified (and by how much) in tuning a specific copter.
@bansiesta Looking inside mc_pos_control, it appears to me that MC_ROLL/PITCH_P are not used in generating attitude setpoints...
@AndreasAntener Thanks, I appreciate you checking my logic; it's easy for me to get directions reversed when interpreting logs.
@SimonWilks It appears to me that, while the mc_pos_control velocity controller is implemented as a PID loop above the attitude controller, the coupling of velocity to attitude causes the potential for instability, since the VEL gains effectively increase the rate gains. I'm no expert on control theory, but couldn't the introduction of a low-pass filter in the velocity controller feedback loop break this coupling?

@kd0aij I think default max yaw rate is a bit too slow. 120 degrees/second means yaw is limited to 3 seconds for a full turn. A value like 240 seems like a better default limit.

A low pass is not a good idea in the control loop. What you really want is a slew rate limiter, which the angular rate limiter implicitly does.

@AndreasAntener @LorenzMeier  BTW while analyzing your log I realized that there was no data logged between 127s and 128s.

@Zefz Are you proposing to also change the default max yaw rate with this PR? I assumed that had been tested before. The defaults for the new max roll and pitch yaw rates may also be too low, but I suppose it's best to err on the side of safety.

I think it is worthwhile to try to make the mixer a bit more intelligent in terms of giving priority to axes at different times. This is an approach that I would like to try out some time:
The desired body-rates are obtained by the imaginary axis of the error quaternion so there is a direct relation between these two vectors. So the rate error vector gives a direct hint which axis is the most critical to control at every time instant because it indicates which axis will lead to the largest attitude error. Now, once one conrol  (e.g. pitch control ) goes into saturation it should be determined if its worthile to give this axis a higher priority compared to e.g. the roll axis. And this I think could be done e.g. based on the rate error vector.
Visualizing the log of @AndreasAntener with FlightAnalyzer I see that the vehicle gets into a large pitch oscillations and eventually flips over the pitch axis. Just before the vehicle flips the log shows that there is a certain demand of roll (but the roll-rate error is significantly smaller than the pitch-rate error, as can be seen in the log at about 125.9s). But you can see from the actuator outputs that due to this roll command the pitch control authority is reduced and thus, the vehicle flips.
Maybe if the mixer gave pitch control full priority the flip could habe been avoided.
Happy to hear comments and opinions.

@kd0aij Yes.

@Zefz OK. Let me know what your testing shows and I'll change the values in this PR. But shouldn't this be an airframe specific parameter?

You are right, it very much depends on the frame. Perhaps it would make more sense to have default values per-frame type.

@tumbili Thanks Roman for having a look. We came to the same conclusion, except that I think it flipped in roll no?. What I don't get is why it changed its mind at 126 and gave a roll rate SP in the direction it was already rolling shortly before hitting 180 degree. But I guess that the controller at this point was already in a bad state..
I'm not sure if I understand what your saying about the mixer. Are you referring to the actual output mixer? Or to some point in the attitude controller? How would this be different from the rate limiter?
I didn't notice the gap in the log before, but you're right, no idea what happened there.

@AndreasAntener Thanks for your comment. Can you have a look at the visualization and tell if you this reminds you of what the quad did? Just clone this repo https://github.com/tumbili/FlightAnalyzer
and run "python plot_maneuver_quad log_file_name.px4log" (you have to copy the log file into the cloned folder). Once you can see the plot you can type into the console "set time 73" which will take you to the instant when things start to get nasty (time is in percent). You can type "p" and "r" to pause and run the visualization. If you are paused you can use "+" or "-" to step forth and back. You can type "sec" to show the current time in seconds (useful if you want to see where you are in the log).
I just think that for such maneuvers euler angles are not suited to be analyzed due to gimbal lock.
The visualization bases on quaternion rotation and should be correct. From what I see in the visualization I think the controller acted correctly but I'm curious to hear your opinion.
About the mixer story: I am referring to the actutal output mixer, the one who takes roll, pitch, yaw and thrust as inputs and computes the motor commands. I just think we could improve the logic of the mixer in case of output saturation (which also happend in your case if you have a look at the motor signals OUT.0-3). This includes situations where the mixer does not allow the engines to produce more moment because one motor reached its upper or lower bound and the mixer does not want to alter the total commanded thrust. In such situations we could imagine that it would be wiser to increase the total thrust and thus, being able to produce a higher moment but accepting a higher thrust output at the same time.

@tumbili Cool script! I can only support your request to put this into FlightPlot, e.g. as a tooltip when you hover over the chart ;) or, another idea, from @sjwilks is: send the time your mouse is at from FlightPlot to the script somehow ;)
Anyway: "acted correctly" can be true/false depending on it's definition. I see that it tries to compensate pitch at 125.6 and the setpoint shoots into the opposite direction which is correct. But it shouldn't have come to that point in the first place. There's also MPC_TILTMAX_AIR which should have prevented it from getting this kind of attitude. We already tried setting this parameter for offboard flights (real and sim) and it does work. But why not in this case is a mystery. Can you think of something there?
Ok, I have to think about your mixer proposal, until know I didn't really look at how the mixer worked.

@AndreasAntener @SimonWilks Thanks for the ideas, will definitely try to get things going.
Will also spend some time on the mixer and maybe improve things there a bit.

I will keep this one dangling a little longer - if we can solve it by having the mixer back-pushing onto the controller to do slew-rate limiting we might be better off, as it will automatically do the maximum rate it can support and yield a similar effect, without introducing yet another parameter.

@kd0aij Is this good to merge? After a long discussion with @tumbili we came to the conclusion we need this, but there are additional steps needed in addition to achieve the two goals we have: One is flight envelope protection, which will mostly be done based on mixer feedback and with reasonable (but high) rate limits. The second goal is customising the user experience (aggressive / soft). That one will probably map partially on this PR, but also on more tuning gains (max velocity / max acceleration). All of them will be limits, so that we don't induce any delay or dependency on tuning gains.

my comment: https://github.com/PX4/Firmware/pull/1928#issuecomment-84611805
indicates that the limiting worked correctly.
@Zefz  commented that the proposed defaults were too low; but since these will be platform dependent, I'm not sure how much they should be increased.

If no-one has a better suggestion, I'll change the roll/pitch defaults to 360 dps and rebase

Sounds fair. An aggressive flip is in the 1000+ dps range, so 360 is still fast, but reasonable.

one more flight test on my FMVv1 450 with 4S/4000 and 8" props
hover thrust level is 62%, PWM 1650usec
POSCTL exhibited no violent glitches on this test with LEA6 in trees

I can see that the limiting was effective in the log, this PR is much appreciated! Merging.


#001 Creating Youtube Rendering Functionality

create a logger.
create a custom exception

its done from dev prospective


Typo in your example

In your example you set the label as ->setLabel('Scan the code') but the QR code label is output as "Label" which some might find confusing.

Thank you, I updated the URL.


ability to dynamically update sidecar polling frequency

You can set it with AEGIS_SIDECAR_POLL_INTERVAL -- will add that to example yaml files with some documentation.


Doesn't detect Friend request screen on NA

Before opening an issue:

[x] I tested the latest release
[x] I read the Troubleshooting Guide
[x] I looked at other issues (even the closed ones)
[x] I'll fill this template properly

Your issue will get closed/locked by the bot in case proper info isn't provided
If you open unnecessary/dumb issues, you'll be rewarded with appropriate tags.

Describe the bug
After a battle, if FGA chooses a non-friend support and the friend request screen comes up  it will go into an infinite loop of waiting for something.
Screenshots

Video
https://cdn.discordapp.com/attachments/755763097788088330/761107089283874816/record_1.mp4
Device Info (please fill at-least 'Device model'):

This icon used to be present before the classes:

I think this might be a glitch in FGO in the latest update and not intended since JP still has that icon:

No, it's not in the same place. See from my screenshot that Follow option changes position of cancel button.
Also, if we just detect Cancel button, we might cancel something we don't want to cancel.

Is the friend request thing still broken? Every time I get to the end of a fight, it skips the friend request if it's there at the end

@randoomdude Friend requests are skipped by default, you can't enable it right now.

Then could you at least just have the script stop at this screen instead of right after it?


push/pop-like operator for array based fields

Currently, the only way to work with array-type fields is to explicitly specify them by index:
Let c be:
{
  members: [
    'member-1',
    'member-2',
    'member-3'
  ]
}

c.get('members.0') // Returns 'member-1'
c.set('members.4', 'member-4')

It would be nice to have a way to push a new element onto the array like so:
c.push('members', 'member-4')
c.pop('members') // Returns 'member-4'
c.pop('members', 0) // Returns 'member-1'

I was thinking about solving this problem and introducing push and pop methods is not enough. We would need all the array methods. So it's not a good solution to duplicate them. Right now you can do as follows:
c.set('members', []);
c.members.push({
  name: 'Name'
});

It will still detect the changes and update them. There is also one more feature that needs implementing. When the new member gets pushed into the array and the document is saved then all members will be saved to the database (not just the one that was pushed). I have to implement detection of changes (diff between arrays).

Thanks for the workaround; That will suffice for me at the moment as I don't foresee my arrays growing more than a set limit. But for future optimization, diffing between arrays would be ideal to reduce I/O in mongo.

Yes right. I definitely have to figure something out.
Regards

That workout didn't work for me? When I try it I get this:
members: { 0: { name: 'Name'}}
Shouldn't it be:  members: { 'Name' } ?
I'm trying to add an item to an array, it's proving difficult, do I need to use collection.update on this? One great thing about astronomy that I've really liked is not having to write these methods.

Could you paste here the code that is not working for you?

Hi Jagi,
found.set('source', []);
       found.source.push({
         name: source._id
      });
    found.save();
On August 3, 2015 at 4:12:24 AM, jagi<EMAIL_ADDRESS>wrote:
Could you paste here the code that is not working for you?
—
Reply to this email directly or view it on GitHub.

When you have class / model:
Founds = new Mongo.Collection('founds');
Found = Astro.Class({
  collection: Founds,
  fields: {
    source: {
      type: 'array',
      default: []
    }
  }
});

then you can do as follows:
var found = new Found();
found.set('source', []); // This line is necessary because we defined default value for the "source" field.
found.source.push({
  name: 'abc'
});
found.save();

The found.source will be equal to [{name: 'abc'}].
Is this exactly what you expect?

That's what I'm going for, how do I get it to work for 'updates'? It seems like this would overwright the array (with found.set('source', []))

With updates it works as well but you don't need to found.set('source', []);.
You just write:
var found = Founds.findOne();
found.source.push({
  name: 'abc'
});
found.save();

That's it

That's great, so then I assume if it's a non-keyed array, it would looke like this: found.source.push('newarrayvalue')?

Yes exactly

This seems to get a little funny with the Meteor.users collection. For one, the collection only allows modifying emails, services, and profiles, so I had to re-work my schema a bit to not get permission errors.
The other thing is, if I store fields in the 'profile' object, even setting a default [] value to an array doesn't create the profile or the array when a user is added. It also doesn't seem to create the array when I do user.profile.set('someArray',[]) (note that user.set('someObject', {}) DOES work).
Looking through issues, it looks like the 'default' portion is related to issue #54.

Instead writing:
user.profile.set('someArray', []);

you have to write:
user.set('profile.someArray', []);

In your schema, you also have to define it like this:
User = Astro.Class({
  /* ... */
  fields: {
    'profile': {
      type: 'object',
      default: {}
    },
    'profile.someArray': {
      type: 'array',
      default: []
    }
  }
});

Maybe it's seems to be a little bit not intuitive. However in the next release, it will change a little bit to something like this:
Profile = Astro.Class({
  name: 'Profile',
  fields: {
    name: {
      type: 'String'
    },
    someArray: {
      type: 'Array',
      default: []
    }
  }
});

User = Astro.Class({
  name: 'User',
  collection: Meteor.users,
  fields: {
    emails: 'Array',
    services: 'Object',
    createdAt: 'Date',
    profile: {
      type: 'Profile',
      default: {}
    }
  }
});

Thanks to that you will have more control over your data and it will be possible to do something like this:
user.profile.set('someArray', []);

as well as this:
user.set('profile.someArray', []);

Huh, I could have sworn I tried that, but I just switched it to what you suggested and it worked perfectly.
I'm sure the new way will be very powerful, but it looks more confusing to me...  (note: I'm pretty new to this stuff, so take it with a grain of salt.) What does it mean to have nested Astro classes? Can you embed another class inside that one? Is it basically creating a reusable schema, and can you use a class to extend another one, or only to define fields?
Thanks!

I'm working on this new release because I want Astronomy to work not only with MongoDB but also with other databases also relational. In most relational databases you can have nested objects or arrays like for instance the Meteor.users collection.
var user = {
  username: 'jagi',
  emails: [ // In SQL databases it would be moved to external table
    { address<EMAIL_ADDRESS>verified: true },
    { address<EMAIL_ADDRESS>verified: false }
  ],
  profile: {}, // In SQL databases it would be moved to external table
  services: {} // In SQL databases it would be moved to external table
};

However in MongoDB or RethinkDB it's possible. So my solution for Astronomy to make it work with other databases is Nested classes.
For example you define that emails are of the Email type. In MongoDB it will be saved just in the user object, however in the SQL it would be saved in the external table. So it's how I'm gonna achieve database abstraction.
Moreover it will be easier to perform many operations because classes are gonna be flat (set of first class fields - no nested fields definition). Nested fields definition will be achieved by using nested classes. I hope it explains everything. If not, let me know I will try to describe it better :)

That makes sense, it's very forward-thinking. What about other class attributes, like what would happen if you put methods on a class that you nested as a field type? That's what really confuses me, that you use the same class to define embedded fields as you do to define the collection objects. On the one hand, it's a very elegant approach, but on the other it seems a bit unstructured, at least visually.
You could do something to clarify that there's a difference with the class, maybe just adding a 'type: field' attribute to the Astro.Class. It doesn't necessarily have to do anything, or perhaps it can disable other class attributes besides fields. Or you could call the class Astro.Field, or something. Just some thoughts.

The difference is in the presence of collection attribute which tells that the class should be persisted in the database. There was an idea to call it just a schema. And compose class from one or many schemas.

I'll just wait and see :)

I've got a question. If i have a field of type array, which in this case, represent the history of the class (for example, an history of the change in prices for an article...). I don't want to pull the full history in memory every time the user is gonna make a change, it could become heavy with time... And because of this, if y try to do in an update :
this.field.push({
   price: priceValue
});

It won't work has it's gonna override the values already there...

var product = Products.findOne();
product.history.push({
  price: priceValue
});
product.save();

The save method will save entire history array, not only the last value. If the list of the operations is long it may not be a good choice to use product.save() to update only this fields. In such situation it would be better to use:
Products.update(product._id, {
  $push: {
    history: {price: priceValue}
  }
});

However, in this situation you have to create your own validation logic. With the new Astronomy release there will be a way to perform validation also in such situations.

Yup, i was already using the classic mongo query on this one. It's not really a problem since i use it in a behaviors where the values have already been validated.
Awesome to hear that the next release will tackle this issue. Astronomy just keep getting better and better ;)

Ok good to hear :). I'm trying to do my best :)

I've implemented the push method for array fields. It works nicely with the new nested fields system. I closer and closer to releasing new version :). For now I'm closing this issue

Awesome. Just so i understand properly, this new version will give me the possibility to push inside an array without having it in memory and without erasing the data already there ?

No, it just introduces push() method that adds element to the array. And later you can same the doc using doc.save(). You have to have it in the memory. The feature are you talking about is in another issue and it's named "direct database access and validation" or something like that :). I don't remember. However, the feature are you talking about will also appear :)

Ok, i guess i'll see directly on the documentation to fully get everything this new version will bring ;)


update flutter 3.0

dart fix --apply
add .idea to .gitignore
issue #44

Thanks

@TheAnkurPanchani Can we merge this pr for a new version of the package, please?

@lazyfatcat : Thanks for the contribution. I really appreciate it.
@CharlesMangwa : Thanks for your help to make this backward compatible.
Latest release is with this change.
card_swiper: ^2.0.4


[Autocomplete] Fix disabled + multiple combination support

[x] I have followed (at least) the PR section of the contributing guide.

This PR forwards the disabled property down to the chip components, which results in the chips being disabled when the Autocomplete component is disabled.
Example: https://codesandbox.io/s/material-demo-yqkrm
Resolves https://github.com/mui-org/material-ui/issues/18915

@cvanem Thank you! :)


Ollama v0.1.18+ does not fully unload from GPU when idle

OS: Ubuntu 22.04
Environment: Docker/nvidia container
Server: Dell Poweredge R720
GPUs: Nvidia Tesla P40 24GB
GPU quantity: 2
Model: any (ie.  dolphin-mixtral:8x7b-v2.5-q6_K)
 docker pull ollama/ollama:0.1.17
 docker run -d --gpus=all -v ~/ollama:/root/.ollama -p 11434:11434 --name ollama17 ollama/ollama:0.1.17
 docker exec -it ollama17 ollama run dolphin-mixtral:8x7b-v2.5-q6_K

Previous observation on Ollama v0.1.17. When model is loaded VRAM utilization is visible via nvidia-smi a pair of processes are also visible:
...p/gguf/build/cuda/bin/ollama-runner
Each process uses 50-150w per GPU while running inference, 50-52w idle but model still loaded.

After a period of idle time, the model is unloaded. Both GPUs drop to 10-12w a piece with no visible process running

 docker pull ollama/ollama:0.1.18
 docker run -d --gpus=all -v ~/ollama:/root/.ollama -p 11434:11434 --name ollama18 ollama/ollama:0.1.18
 docker exec -it ollama18 ollama run dolphin-mixtral:8x7b-v2.5-q6_K

Observation on Ollama v0.1.18. When model is loaded VRAM utilization is visible via nvidia-smi a pair of processes are also visible, but under a different path:
/bin/ollama
Each process uses 50-150w per GPU while running inference, 50-52w idle but model still loaded.

After a period of idle time, the model is unloaded, but process is still running. Both GPUs pull equivalent wattage as idle/model loaded.

The server is powered on 24/7 and tuned to pull 120w w/o GPUs. Ollama is idle 95% of time. Prior, P40s were adding a combined 24w additional power draw idle under v0.1.17. Now with v0.1.18, the P40s adding a combined 110w additional power draw. 86w difference.
Does /bin/ollama need to be running the entire time?

In 0.1.17 we leveraged a subprocess for the LLM runner accessing the GPU.  After 5min of idle time, that subprocess was terminated, releasing all GPU allocations.  In 0.1.18 we've transitioned to loading the LLM logic in-process, and while we're still unloading after 5min of idle, it looks like there's still some GPU memory allocation that isn't being freed up.

In 0.1.17 we leveraged a subprocess for the LLM runner accessing the GPU. After 5min of idle time, that subprocess was terminated, releasing all GPU allocations. In 0.1.18 we've transitioned to loading the LLM logic in-process, and while we're still unloading after 5min of idle, it looks like there's still some GPU memory allocation that isn't being freed up.
Yeah, I've noticed this: I can set num_gpu to a very tight value and it works fine when I load the model from a newly created (or newly respawned after OOM), but if I try to swith models then I get OOM error. From looking at nvidia-smile it's the wrapped llama.cpp server that isn't freeing all it's VRAM.

Digging around a bit more, I believe this is the result of llama.cpp not completely freeing up VRAM resources when the model is freed up. e.g. https://github.com/ggerganov/llama.cpp/issues/3717
We'll take a look at it, and keep an eye on upstream as well.

Could be the cause of https://github.com/jmorganca/ollama/issues/1691

With a slight modification to server.cpp and ggml-cuda.cu, I was able to get the upstream server to run under the cuda memory leak checker tool, and was able to find 4 leaks.
========= Leaked 8,388,608 bytes at 0x7faf2c000000
=========     Saved host backtrace up to driver entry point at allocation time
=========     Host Frame: [0x2db39f]
=========                in /lib/x86_64-linux-gnu/libcuda.so.1
=========     Host Frame: [0xc33c3e]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame: [0xc00373]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame: [0xc422f5]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame: [0x8aa9bd]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame:cublasCreate_v2 [0x7f66f1]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame:ggml_init_cublas.part.0 in /home/daniel/code/llama.cpp/ggml-cuda.cu:8008 [0x199ee2]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:ggml_init in /home/daniel/code/llama.cpp/ggml.c:2428 [0x159070]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:llama_backend_init in /home/daniel/code/llama.cpp/llama.cpp:11191 [0xf1f8e]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:main in /home/daniel/code/llama.cpp/examples/server/server.cpp:2546 [0x25093]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:__libc_start_call_main in ../sysdeps/nptl/libc_start_call_main.h:58 [0x29d90]
=========                in /lib/x86_64-linux-gnu/libc.so.6
=========     Host Frame:__libc_start_main in ../csu/libc-start.c:379 [0x29e40]
=========                in /lib/x86_64-linux-gnu/libc.so.6
=========     Host Frame:_start [0x2e345]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========
========= Leaked 1,024 bytes at 0x7faf2dc00000
=========     Saved host backtrace up to driver entry point at allocation time
=========     Host Frame: [0x2db39f]
=========                in /lib/x86_64-linux-gnu/libcuda.so.1
=========     Host Frame: [0xc33c3e]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame: [0xc00373]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame: [0xc422f5]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame: [0x8aa9bd]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame: [0x8aa20b]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame:cublasCreate_v2 [0x7f66f1]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame:ggml_init_cublas.part.0 in /home/daniel/code/llama.cpp/ggml-cuda.cu:8008 [0x199ee2]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:ggml_init in /home/daniel/code/llama.cpp/ggml.c:2428 [0x159070]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:llama_backend_init in /home/daniel/code/llama.cpp/llama.cpp:11191 [0xf1f8e]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:main in /home/daniel/code/llama.cpp/examples/server/server.cpp:2546 [0x25093]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:__libc_start_call_main in ../sysdeps/nptl/libc_start_call_main.h:58 [0x29d90]
=========                in /lib/x86_64-linux-gnu/libc.so.6
=========     Host Frame:__libc_start_main in ../csu/libc-start.c:379 [0x29e40]
=========                in /lib/x86_64-linux-gnu/libc.so.6
=========     Host Frame:_start [0x2e345]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========
========= Leaked 131,072 bytes at 0x7faf2dc00400
=========     Saved host backtrace up to driver entry point at allocation time
=========     Host Frame: [0x2db39f]
=========                in /lib/x86_64-linux-gnu/libcuda.so.1
=========     Host Frame: [0xc33c3e]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame: [0xc00373]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame: [0xc422f5]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame: [0x8aa9bd]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame: [0x8aa22e]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame:cublasCreate_v2 [0x7f66f1]
=========                in /usr/local/cuda/lib64/libcublas.so.12
=========     Host Frame:ggml_init_cublas.part.0 in /home/daniel/code/llama.cpp/ggml-cuda.cu:8008 [0x199ee2]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:ggml_init in /home/daniel/code/llama.cpp/ggml.c:2428 [0x159070]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:llama_backend_init in /home/daniel/code/llama.cpp/llama.cpp:11191 [0xf1f8e]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:main in /home/daniel/code/llama.cpp/examples/server/server.cpp:2546 [0x25093]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:__libc_start_call_main in ../sysdeps/nptl/libc_start_call_main.h:58 [0x29d90]
=========                in /lib/x86_64-linux-gnu/libc.so.6
=========     Host Frame:__libc_start_main in ../csu/libc-start.c:379 [0x29e40]
=========                in /lib/x86_64-linux-gnu/libc.so.6
=========     Host Frame:_start [0x2e345]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========
========= Leaked 2,097,152 bytes at 0x4ea000000
=========     Saved host backtrace up to driver entry point at allocation time
=========     Host Frame: [0x2e90ad]
=========                in /lib/x86_64-linux-gnu/libcuda.so.1
=========     Host Frame:ggml_cuda_pool_malloc_vmm(int, unsigned long, unsigned long*) in /home/daniel/code/llama.cpp/ggml-cuda.cu:7834 [0x1b2e12]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:ggml_cuda_op_mul_mat(ggml_tensor const*, ggml_tensor const*, ggml_tensor*, void (*)(ggml_tensor const*, ggml_tensor const*, ggml_tensor*, char const*, float const*, char const*, float*, long, long, long, long, CUstream_st*), bool) in /home/daniel/code/llama.cpp/ggml-cuda.cu:9398 [0x1b4004]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:ggml_cuda_compute_forward.part.0 in /home/daniel/code/llama.cpp/ggml-cuda.cu:10632 [0x19a3f5]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:ggml_backend_cuda_graph_compute(ggml_backend*, ggml_cgraph*) in /home/daniel/code/llama.cpp/ggml-cuda.cu:11323 [0x19a862]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:ggml_backend_sched_graph_compute in /home/daniel/code/llama.cpp/ggml-backend.c:1583 [0x179330]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:llama_decode_internal(llama_context&, llama_batch) in /home/daniel/code/llama.cpp/llama.cpp:7722 [0xf8eed]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:llama_decode in /home/daniel/code/llama.cpp/llama.cpp:12287 [0xf9aa3]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:llama_init_from_gpt_params(gpt_params&) in /home/daniel/code/llama.cpp/common/common.cpp:1361 [0xd8e6d]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:llama_server_context::load_model(gpt_params const&) in /home/daniel/code/llama.cpp/examples/server/server.cpp:383 [0x8024d]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:main in /home/daniel/code/llama.cpp/examples/server/server.cpp:2669 [0x262d4]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========     Host Frame:__libc_start_call_main in ../sysdeps/nptl/libc_start_call_main.h:58 [0x29d90]
=========                in /lib/x86_64-linux-gnu/libc.so.6
=========     Host Frame:__libc_start_main in ../csu/libc-start.c:379 [0x29e40]
=========                in /lib/x86_64-linux-gnu/libc.so.6
=========     Host Frame:_start [0x2e345]
=========                in /home/daniel/code/llama.cpp/build/./bin/server
=========
========= LEAK SUMMARY: 10617856 bytes leaked in 4 allocations
========= ERROR SUMMARY: 4 errors

The first 3 are all the same call site and the fix is pretty straight forward.  We just need to add a call to cublasDestroy at shutdown of the server.
I haven't quite figured out the last one yet thought.

Hi @dhiltgen! I think this one might not be fully fixed as of version 0.1.27.
I am also running an Nvidia P40 on Linux and still see around 50w of GPU usage and around 230mb of GPU memory occupied after the chat session is stopped and in idle mode.
The only thing that helps fully unload the GPU is restarting the service manually by calling sudo service ollama restart.
Here is the nvidia-smi output after the session has been closed and server was idle for a while (over 5 minutes):
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 545.23.08              Driver Version: 545.23.08    CUDA Version: 12.3     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  Tesla P40                      On  | 00000000:01:00.0 Off |                  Off |
| N/A   57C    P0              53W / 175W |    240MiB / 24576MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|    0   N/A  N/A       825      G   /usr/lib/xorg/Xorg                            4MiB |
|    0   N/A  N/A   1670919      C   /usr/local/bin/ollama                       234MiB |
+---------------------------------------------------------------------------------------+

and here is another output after forcefully restarting the service:
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 545.23.08              Driver Version: 545.23.08    CUDA Version: 12.3     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  Tesla P40                      On  | 00000000:01:00.0 Off |                  Off |
| N/A   44C    P8              10W / 175W |      4MiB / 24576MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|    0   N/A  N/A       825      G   /usr/lib/xorg/Xorg                            4MiB |
+---------------------------------------------------------------------------------------+

OS: Debian 12
Environment: Bare metal
GPUs: 1x Nvidia Tesla P40 24GB
Other hardware: Intel 8gen B360 mobo + i5 8600, 16gb DDR4
Model: any (e.g. miqu-1-70b.q2_K)
Please let me know if I can be of any help

Due to the way llama.cpp allocates memory on VMM vs. non-VMM cards, the fix seems to only be complete on VMM cards.  I've opened a new issue #2767 to track fixing this for non-VMM GPUs.

Actually I don't think this fix is complete for VMM either - tried this in Docker+Nvidia Container like the original poster did and still getting idle GPU usage on 0.1.27:
docker pull ollama/ollama:0.1.27
docker run -d --gpus=all -v ~/ollama:/root/.ollama -p 11434:11434 --name ollama-27 ollama/ollama:0.1.27
docker exec -it ollama-27 ollama run dolphin-mixtral

When model is loaded and active:
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 545.23.08              Driver Version: 545.23.08    CUDA Version: 12.3     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  Tesla P40                      On  | 00000000:01:00.0 Off |                  Off |
| N/A   48C    P0              58W / 175W |  22688MiB / 24576MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|    0   N/A  N/A       828      G   /usr/lib/xorg/Xorg                            4MiB |
|    0   N/A  N/A    177482      C   /bin/ollama                               22682MiB |
+---------------------------------------------------------------------------------------+

After 5 minutes of inactivity:
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 545.23.08              Driver Version: 545.23.08    CUDA Version: 12.3     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  Tesla P40                      On  | 00000000:01:00.0 Off |                  Off |
| N/A   54C    P0              53W / 175W |    238MiB / 24576MiB |      0%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|    0   N/A  N/A       828      G   /usr/lib/xorg/Xorg                            4MiB |
|    0   N/A  N/A    177482      C   /bin/ollama                                 232MiB |
+---------------------------------------------------------------------------------------+

While the older v0.1.17 fully unloads when idle, consistent with @richginsberg's initial report.

This should be resolved by #3218

This should be resolved by #3218

Just tested v0.1.30, the issue is still present.

This should be resolved by #3218

Not fixed for me. Before updating, ollama didn't use any (significant, at least) memory on startup. Now, the instance mapped to my 1080 Ti (11 GiB) is using 136 MiB and the instances mapped to my 1070 Ti's (8 GiB) are using 100 MiB each. This is before loading any models. Not too cool. Restarting flushes memory, but then refills

To clarify, there is a new failure mode, in v0.1.30. In previous versions, the ollama process would unload model and then the process persisted in GPU memory until restart of the ollama process/docker container. In v0.1.30, ollama also loads itself into memory after restart. This makes things more challenging as in the case of a card like Telsa P40, there is continuous 50W draw from the card on an idle system.

Above I confirmed the issue persists in v0.1.30. To confirm is wasn't new from v0.1.30, I tried in v0.1.29. Same issue.
docker run -d --gpus=all -v /home/username/ollama:/root/.ollama -p 11434:11434 --name ollama29 ollama/ollama:0.1.29

I guess we'd all have to check the future version 0.1.31 since the fix was only merged like an hour ago :)

I just tested with 0.1.31 and my P40s are still affected. With 0.1.17 the gpus get released properly.

Fixed for me in ollama/ollama:0.1.32. Thanks a bunch!


Docs for "Dot functions"

Description
This documents how to use .where() and similar functions
Questions

What should these be called?

Dot functions
Query functions
Mutator functions
something else?

Checklist

[ ] For UI or styling changes, I have added a screenshot or gif showing before & after
[ ] I have added a changeset
[x] I have added to the docs where applicable
[ ] I have added to the VS Code extension where applicable

@archiewood I think query functions would be more self-explanatory.

Agreed. "Dot functions" makes me think of Dotfiles https://www.daytona.io/dotfiles/ultimate-guide-to-dotfiles


[Backend]: Add Docker support for development and production

To Helps with initial setup and ensures the integrity of the app
Add docker support for the development and production environment. Creating a Dockerfile and docker-compose files, Adding all the necessary environment like Mysql together with compose.

@navarrojava
Any updates on the progress?


Creating a new patient during OPD check-in, resulting visit page not quite right

Expected behavior:
When checking in a new patient on the "Todays Outpatient" page, the new patient record record is to be created and a new  open visit of type "clinic" is to be created.   That visit looks and behaves the same as any other visit.
Actual behavior:
The resulting visit page is not titled "Edit Visit" it is titled "Patient CheckIn",  and it has a "Check-in"  button.
Patient is created properly, and if you navigate to the patient, the new visit is there, but it is the same as above; it does not look like a regular Edit Visit page.
Also, when creating the visit and new patient, there is a dialog pop-up message on the visit being created, but not for the patient being created.
Steps to reproduce:

navigate to Patients > Outpatient
Click Patient Check-in
Enter a brand new patient
Enter the patient data on the new patient dialog, click the add to add the new patient.

Screenshots (if applicable):

OS and Browser:
OSX 10.10.5,  Chrome 55.0.2883.75 (64-bit)

@jkleinsc


Extremes clean up

Coverage increased (+0.05%) to 93.582% when pulling dfba6ed42a17bc05d6472944f75e254fe4bb814c on thongsav-usgs:master into 2cdec62679555924e4d85458fed43a4acc1a0030 on USGS-R:master.


Make wavefd API Object Oriented

I have very little taste for OOP and generally prefer functions over classes whenever possible. This is how most of the forward modeling modules in Fatiando work (like fatiando.gravmag.prism). So this is how I implemented the initial fatiando.seismic.wavefd. It has functions that take the velocity model and simulation parameters and produce iterators for the simulation. It works well enough so far.
The problems with this approach:

requires a lot of function arguments
verbose to setup
hard to automate animation in matplotlib in a general way
very difficult to persist a simulation (using pickle) and resume it later (the user needs to know what to pickle and things can get messy)

This last point is what bugs me the most. Long running simulations would benefit from saving checkpoints that can be used to resume at later times or if things crash.
One way to easily resolve most of these issues is to move to an Object Oriented approach. That way, each type of simulation (acoustic, SH, P-SV, 3D-acoustic) would have its own class. The class would be in charge of setting up the simulation parameters (time step, sources, recording stations, saving snapshots to file, etc.) and velocity model (maybe even include conversion to Lamé parameters?). Each class would have the following methods:

run: run the simulation for a given amount of time (starting from the time step)
step: take a single time step
animate: make a plot animating the simulation using matplotlib.animate

There would be no real need for complex class hierarchy because most methods would have to be reimplemented anyway since they are problem specific.
Update: I've made a prototype of these classes on an IPython notebook.  This is the list of things that I'll try to do soon:

[x] Store the source as pickled string in HDF5
[x] Use Abstract Base Classes for WaveFD2D
[x] Fix problem with plots on non-square domains
[x] Better use of HDF5 attributes to store metadata (should store the Fatiando version string as well)
[ ] Set sampling rate and don't store all time steps to disk

After these things are done in the prototype, I'll put them in a branch and make a PR.

After discussion with @eusoubrasileiro, we're going to copy the work done in #137 onto a new branch to get rid of the clutter on that PR. We'll take the lessons learned from there and try to make a better design before writing any more code.
A current list of things to change:

Make wavefd a package to reduce file sizes
Import the useful classes in __init__.py
Standardize the metadata storage in the HDF5 files
Move wavelet classes to a new module so that they can be reused elsewhere (like seismic.conv)
Move some of the plotting code to vis
Try to get rid of Cython compiled code (maybe with clever numpy indexing or numba or both)?
Tests!
Accept a SquareMesh object instead of numpy arrays  to make it  more like other Fatiando code?

#259 discusses an item on the wishlist for wavefd: a method for extracting seismograms that interpolates the wavefield on to specific points (instead of getting the closes node).

wow after a lot of time I am getting back to this! I am using the old psv code again....
I suggest we sit down some day to try to this together. The design part isn't a easy task...
I will write down here a little suggestion for future use: "separate the embedding jupyter part from the main code".

Yep, I have to agree on that. I've been thinking about this lately and I'll have to get this done soon for my classes. So it finally became a priority again.


Complete refactor of ruby code

Why?

It was in need of a refactor.

What changed?

Completely refactored the ruby code for tape. It now uses thor for the command line interface, and it's much more organized.

Nobody merge this yet. I'm working on adding some tests for it.

@dkniffin THIS is pretty freakin D O P E
I like the overall structure of this code. Reads very well and make the running layer much easier to extend. Nice work 👍
Only question I have is, does this change the structure of any of the cli commands?

@BrandonMathis I did remove some of the existing commands, because I don't think they were used. Specifically, these. It looks like I also removed the two that were added recently. Those should probably be added to the new code.
For deploy and everything I tried to keep everything as consistent with the current commands as possible.

Awesome. So freakin awesome. Thanks for doing this!


Enable-WriteCore-for-Azure.AI.OpenAI.Assistants

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.AI.OpenAI.Assistants


#31 GetAll diagnostics as per new LSP

PR for https://github.com/scalameta/nvim-metals/issues/31

Thanks for sending this in @landerlo! I plan to review this later this week. I haven't really been keeping up with the LSP changes in nvim, and there seems to be a lot that has changed, and my entire setup is now broke. So I want to take a bit of time to really get caught up, and then I'll properly review this.


Can't disable NUMA tab for VM templates

Description
Sunstone views are not allowing to disable NUMA tab
To Reproduce

Specify:templates-tab:
    actions:
        Template.numa: true
    template_creation_tabs:
        numa: true

Try to create new template

Expected behavior
NUMA tab is disabled
Details

Affected Component: Sunstone
Hypervisor: KVM
Version: 5.10.2

Additional context
https://github.com/OpenNebula/one/blob/2134aabb9dd91bd1223e592234ddab90ed53158c/src/sunstone/etc/sunstone-views/mixed/admin.yaml#L276

Progress Status

[ ] Branch created
[ ] Code committed to development branch
[ ] Testing - QA
[ ] Documentation
[ ] Release notes - resolved issues, compatibility, known issues
[ ] Code committed to upstream release/hotfix branches
[ ] Documentation committed to upstream release/hotfix branches

Thanks!


Bump versions / permit build with JDK11

Support builds on newer JDKs

Update tycho-compiler-jdt in analytics/pom.xml
Ignore spotbugs RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE for JDK11
Bump several plugins to latest (maven-compiler-plugin, etc.)
Add profile for using -release flag in Eclipse and with JDK9 and later

Fix recently added warnings

Add try-with-resources for TreeCache objects to remove recent warnings
Suppress generics warning in MetricCompactionStrategy
Update TabletMetadataConsole to avoid deprecated Accumulo
ClientConfiguration API

Other

Bump jackson-databind for CVE-2019-14439, CVE-2019-14379
Bump hadoop 2.7 to latest in series (2.7.3->2.7.7) for build

Nothing in this should have any impact on building with JDK8.


Ratings should be considered tags.

What is your suggestion for the program?

It should be able to set the rating of an image (Explicit, Questionable, Safe)
as a tag that folders can be named. When I attempt to do so, there is no
failure report or anything like that, it just pretends it wasn't a token. If it
can already do that I would appreciate some instructions.

What version of the product are you using? On what operating system?

v3.2.7 Windows

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 7 Apr 2013 at 7:20

The problem lies with the detection of the rating itself (you can use the %rating% token in filenames).
Please provide more details on which source and tag you're searching and I'll investigate, but I think it goes for another issue.


jwt security is broken

@AuthenticationPrincipal doesn't work, we need to fix it
@IlyaLisov

@IlyaLisov can you check it?

auth non null


Tooltip not closing when clicking outside of icon

Issue description:
The tooltip is not closing when clicking outside the icon. So if the user clicks on the tooltip icon and then continues working, the tooltip will still be shown.
Video: https://cl.ly/iYl0
Version used:
2.4.0-beta.1
Using theme_mods or options?
theme_mod
Code to reproduce the issue (config + field(s))
Standard tooltip implementation.

Good catch!
Fixed 👍


MudTabs: Fix JsInteropException when trimmed binary (#6050)

Description

Fixes #6050
I implemented a CustomJson converter for BoundingClientRect to resolve a issue i encountered when using the latest build of MudBlazor, during investigation of the issue i found out that the issue only happened in trimmed binaries.
The converter only supports deserialization as i could not find any use case for it being needed for serialization.
How Has This Been Tested?

It's both been tested using my own Blazor application with a custom build of MudBlazor and using a Unit test to verify that it doesn't crash and gets the correct values as expected.
Types of changes

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

Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[x] I've added relevant tests.

@ScarletKuro Would you mind reviewing please.
Why do the Docs work?
Is it due to this
https://github.com/MudBlazor/MudBlazor/blob/dc399ae15b7cff79d6859d337beab78d445169cb/src/MudBlazor.Docs.Wasm/MudBlazor.Docs.Wasm.csproj#L9

@Swizzy Just checking.  Are you using AOT?

@Swizzy Just checking. Are you using AOT?

No, i don't use anything special, i just set this project up the other day from one of the .NET 7 empty templates, added MudBlazor and JSON.NET to resolve another serialization issue where i am in more control.

Ok so this could be a JSON.net issue?
I really need a repro before merging this since the Docs is working.

@mikes-gh

Is it due to this <_AggressiveAttributeTrimming>false</_AggressiveAttributeTrimming>?

No, this just prevents from trimming some attributes that Docs is using, for example System.ObsoleteAttribute.
This is most likely because of this line
https://github.com/MudBlazor/MudBlazor/blob/5d6ba1b42ab3a444fe68e0329ee8b44533171aba/src/MudBlazor/Services/ReseizeObserver/ResizeObserver.cs#L58
Even thought InvokeAsync(it's converting the object into json inside) is annotated InvokeAsync<[DynamicallyAccessedMembers(JsonSerialized)] but this is wrapped into an IEnumerable so I guess some properties inBoundingClientRect get trimmed. I do not think this requires adding a JsonConverter and you can fix it with DynamicDependency.

OK so we still need to answer the question why does it work on Docs?
BTW @Swizzy I think you're going to have issues with JSON.net with trimming.  System.Text.Json has good trimming support including code generators which NewtonSoft have said they wont support as its too much work.

Maybe because IconsPage is referencing BoundingClientRect? It's theory only

Is this a reproduction repo https://github.com/Swizzy/ZENBitPackToolbox ?

Is this a reproduction repo https://github.com/Swizzy/ZENBitPackToolbox ?

I had the issue there before my last commit yes - i'm trying to set up a cleaner repo for you guys with nothing but this issue to make it easier to narrow things down :)

A repro repo can now be found here; https://github.com/Swizzy/MudBlazorJSInteropRepro
As minimalist as possible; setup a new template, added MudBlazor (and only MudBlazor), made the changes as per the instructions to include the CSS/JS and added a MudTabs component with 3 pages with no special content and made it deploy to GH Pages (where i personally found the issue).
you can see it in action here; https://swizzy.github.io/MudBlazorJSInteropRepro

OK so we still need to answer the question why does it work on Docs?
BTW @Swizzy I think you're going to have issues with JSON.net with trimming. System.Text.Json has good trimming support including code generators which NewtonSoft have said they wont support as its too much work.

Thanks for the heads up, i'll look into making it work with System.Text.Json, but i felt like switching over to NewtonSoft to be an OK quick fix as it solved the problem i had at the time (not related to this one)

@mikes-gh

Is it due to this <_AggressiveAttributeTrimming>false</_AggressiveAttributeTrimming>?

No, this just prevents from trimming some attributes that Docs is using, for example System.ObsoleteAttribute.
This is most likely because of this line
https://github.com/MudBlazor/MudBlazor/blob/5d6ba1b42ab3a444fe68e0329ee8b44533171aba/src/MudBlazor/Services/ReseizeObserver/ResizeObserver.cs#L58
Even thought InvokeAsync(it's converting the object into json inside) is annotated InvokeAsync<[DynamicallyAccessedMembers(JsonSerialized)] but this is wrapped into an IEnumerable so I guess some properties inBoundingClientRect get trimmed. I do not think this requires adding a JsonConverter and you can fix it with DynamicDependency -> [DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(BoundingClientRect))] to the ResizeObserver.

I tried adding [DynamicallyAccessedMembers(PublicConstructors)] and later also [DynamicallyAccessedMembers(PublicParameterlessConstructor)] with and without a empty parameterless constructor without success previously.
My first thought was that that should be sufficient aswell, it's entirely likely that what you mentioned is the reason the docs work - if those somewhere instantiate a new BoundingClientRect that could very well be the reason it works fine in the docs as it obviously then uses the constructor that is missing according to the error messages

Ty for repository, I could reproduce it. It indeed gets trimmed, if you open with DotPeetk for example, thats what you will see inside the BoundingClientRect
namespace MudBlazor.Interop
{
  public class BoundingClientRect
  {
    public double Width
    {
      [MethodImpl(MethodImplOptions.NoInlining)] get => throw new NotSupportedException("Linked away");
    }

    public double Height
    {
      [MethodImpl(MethodImplOptions.NoInlining)] get => throw new NotSupportedException("Linked away");
    }
  }
}

I also reproed it here https://mudblazor-test2.azurewebsites.net/ in azure.

[DynamicallyAccessedMembers(PublicParameterlessConstructor)] are not enough, because the properties gets trimmed as well, they are needed for JS interop as well. I verified that [DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(BoundingClientRect))]. Instead of All we probably could use DynamicallyAccessedMemberTypes.PublicMethods | DynamicallyAccessedMemberTypes.PublicProperties | DynamicallyAccessedMemberTypes.NonPublicConstructors but since we started to use All I think it's better to have the code consistency.

I also noticed that linker from .net6 wasn't touching this class, maybe this is why it was left unnoticed for this long. This kind of interop is really tricky, since the compiler won't give you any warrning.

[DynamicallyAccessedMembers(PublicParameterlessConstructor)] is not enough, because the properties gets trimmed as well, they are needed for JS interop as well. I verified that [DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(BoundingClientRect))] works. Instead of All we probably could use DynamicallyAccessedMemberTypes.PublicMethods | DynamicallyAccessedMemberTypes.PublicProperties | DynamicallyAccessedMemberTypes.NonPublicConstructors but since we started to use All I think it's better to leave as as to have the code consistency.

Thanks @ScarletKuro I think we should use the minimum required access but thats me.  When there is lots of member types I guess the trimming difference is less.  But I think All was used initially when we were discovering triming and we shouldnt use it as the standard

I think All was used initially when we were discovering triming

Yeah. And you are right, that we should use minimum required for optimization, but maybe we should do it as separate PR? Up to you, idm any variant.

Closed in favour of https://github.com/MudBlazor/MudBlazor/pull/6053
@Swizzy Thanks for the report

I think All was used initially when we were discovering triming

Yeah. And you are right, that we should use minimum required for optimization, but maybe we should do it as separate PR? Up to you, idm any variant.

We can narrow down access in another PR

Ok. I left comment in the PR for future.


Add empty index.js in the alpha 1.0.0 version

I wanted to try the alpha version, but Gatsby was complaining that it could not find gatsby-source-strapi plugin anywhere. This is because there is no index.js that Gatsby uses to identify plugins.

Hello, please install the plugin through the NPM registry:
# Using Yarn
yarn add gatsby-source-strapi

# Or using NPM
npm install --save gatsby-source-strapi

The problem shoudn't occur when you do this


Feature/Tooltip enhancements and tests

summary
additions/changes to tooltip:

event callbacks for open, close, blur, focus, mouseenter, and mouseleave

props to disable mouse or focus events

separated delay into enterDelay and leaveDelay

testId prop (testing convenience for both contributors and library users)

tests!

@sheminusminus Now that's a great job! I had to change the base and now we got some conflicts. (we're merging PRs to 'develop' branch and the PR was submitted for 'master'). Can you rebase it to get rid of the changes in package-lock.json and readme? ☺

@arturbien Commit history is a little weird from getting on par with develop, but I'll squash and merge :) should be ready to review though!

:tada: This PR is included in version 3.0.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Question: support hardware "Connair" (foto inside) possible?

Describe you new feature you'd like
Hi all,
at first I want to say thanks to that project - I have it running smoothly for some weeks and it works quite nice.
I remembered I used a project called "Connair" a few years ago:
Device: https://www.amazon.de/ConnAir-433-Home-Automation-Gateway/product-reviews/B008W1G620
Project page: I'll try to find it....
My question is, if this device can anyhow used with this somfy project - I know it's not a ESP32 but maybe someone has an idea. Here is a foto:

Thanks and regards
Carl

This will not work with ESPSomfy RTS.  That processor is not supported.

I am going to close this as I don't plan on supporting this hardware.


fix: page crashing on invalid url in embed block

(relates to RM-74)
🧰 Changes
We're seeing an issue in the new embed block where the page crashes when trying to render a populated embed. Here's a video of me having a lovely time with it, entering the (valid) YouTube URL https://www.youtube.com/watch?v=tE0wh-RKhR0:
https://user-images.githubusercontent.com/48635728/158707361-47e3342f-eb71-4c65-9109-f3f68ce1a135.mov
The error returned is this one:

We've tracked this down to the switch statement inside magic-block-parser,, where we assign a value to json.provider.
We go on to use this json.provider as a title here.
By wrapping this assignment in a try catch statement, we avoid the page crashing entirely and instead assign an empty string as the provider. If anyone sees a problem with this please shout!
In the new embed block we are validating the URL entered before we try to render the block, so honestly it's still a bit of a mystery why this is happening at all... I'm still not sure how we're hitting this point of the switch statement inside the parser. I wonder if perhaps we're starting to render the block before embedly returns all the data, but if that were the case I'd expect us to return at the top of the switch statement in the magic block parser and never hit this line of code. 🤷♀
🧬 QA & Testing

Broken on production.
Working in this PR app.

This PR was released!
🚀 Changes included in v6.38.5


broken request if parameter contains ";"

hey @mrjones ,
first of all, thanks for the nice library!
i'm trying to re-use it in upwork/golang-upwork project, and i've found an interesting issue:
params := make(map[string]string)
params["q"] = "golang"
params["paging"] = "1;10"

line 675: t := userRequest.URL.Query()
line 676: log.Fatal(userRequest)
2015/08/10 07:59:26 &{GET https://www.upwork.com/api/profiles/v2/search/jobs.json?paging=1;10&q=golang HTTP/1.1 1 1 map[] <nil> 0 [] false www.upwork.com map[] map[] <nil> map[]   <nil>}

seems to be OK, but:
line 677: log.Fatal(t)
2015/08/10 08:02:40 map[10:[] q:[golang] paging:[1]]
HOW?!

let's change params[q] to params["q"] = "golang;test"
userRequest looks correct:
2015/08/10 08:11:25 &{GET https://www.upwork.com/api/profiles/v2/search/jobs.json?q=golang;test&paging=1;10 HTTP/1.1 1 1 map[] <nil> 0 [] false www.upwork.com map[] map[] <nil> map[]   <nil>}
but suddenly userRequest.URL.Query() returns:
2015/08/10 08:12:51 map[paging:[1] 10:[] q:[golang] test:[]]

jfyi, URL.Query() recognizes ";" and "&" as delimeters (http://stackoverflow.com/questions/3481664/semicolon-as-url-query-separator)
quick fix can look like:
diff --git a/oauth.go b/oauth.go
index 3d195ce..d1b9b61 100644
--- a/oauth.go
+++ b/oauth.go
@@ -669,6 +669,7 @@ func (rt *RoundTripper) RoundTrip(userRequest *http.Request) (*http.Response, er
        if userRequest.Header.Get("Content-Type") !=
                "application/x-www-form-urlencoded" {
                // Most of the time we get parameters from the query string:
+               userRequest.URL.RawQuery = strings.Replace(userRequest.URL.RawQuery, ";", "%3B", -1)
                for k, vs := range(userRequest.URL.Query()) {
                        if len(vs) != 1 {
                                return nil, fmt.Errorf("Must have exactly one value per param")

in that case library works as expected
or the library could encode ";" before creating a request (and might decode it before signing a request to have a valid signature created), or smth similar

Hi! Thanks so much for the extremely well researched bug report, and I'm really sorry that it's taken me so long to reply.
This is a tricky one!! Since: it is not clear to me whether its "Right" to consider ";" a separator or not.
Personally, I had never considered semicolon a separator.  On the other hand, clearly the Go authors do, and (from your link) the W3C says:
"We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner."
http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2
Neither choice seems obviously right (or wrong), so we've just got to choose one.
I'm inclined to consider semicolon a separator, primarily because the behavior of url.Query seems like a reasonable precedent to follow for Go programs.
Once we assume that decision, that implies two things:

This library should continue to treat semicolon as a separator and not make any changes.
For users, like you, who want to embed a semicolon without it being treated as a separator, they should escape it in application code, before sending it in.

So, my suggestion is that you change the URL you pass to GET to:
https://www.upwork.com/api/profiles/v2/search/jobs.json?paging=1%3B10&q=golang
I hope that this is a reasonable compromise that should allow applications to continue to use semicolon as a separator (by passing ";" raw) or not (by passing %3B).
Please do let me know if this works for you!

@mrjones , unfortunately your suggestion won't work, because by specifying "%3B" in the parameter, means that "%" will be encoded as "%25" and the final url will contain "%253B" - as a result, server side never decodes "%253B" to ";"
i understand that old rfc describes ";" and "&" as delimiters, but it's far from reality nowadays :)

Ah, I think I understand better now.  However, I could still be mis-understanding something, if so please let me know.
I just committed change c4fac5ef43dacbdd6dfe0b159fb24b0e33ea5bbb which I hope will help you.
To communicate fully what's happening here, I must point out that as of recently, there are two different ways to make HTTP requests.  This all started with 5faa557585ac2fde321eada0a28eb6f1b4176319, when I introduced a second way.

The old way works by calling Get()/Post()/etc directly on the Consumer object.
The new way works by using an http.Client from the MakeHttpClient method on the Consumer.

I think the second way is more flexible, and generally "better", but I'd like to keep both ways working.  So, there is a function (makeAuthorizedRequestReader) which translates from the old interface to the new one internally.
Correct me if I'm wrong, but I assume that you are using the "old" way (calling Get directly)?    People who use the new interface should be able to access to RawQuery directly on the http.Request object, and therefore shouldn't need any special support inside the library.
Assuming I understand correctly: We only need to fix the old interface.  Therefore, I applied the exact fix that you recommended (replacing ";" with "%3B" in the RawQuery) in the old-to-new translation method (makeAuthorizedRequestReader).
I hope this will fix your code as it stands. I also believe you could switch to the new http.Client interface, which would enable you to control the escaping yourself by editing RawQuery.  You might like other aspects of the new interface as well.
I committed two tests as part of c4fac5ef43dacbdd6dfe0b159fb24b0e33ea5bbb, to demonstrate what I think should happen.
Please do let me know if this fixes your issue!

@mrjones , actually, i use a new method, i.e. MakeHttpClient, and i can move the fix under my hood :)
i believed:

other could experience the same issue; moreover, i wasn't sure about the root and history of the issue - thanks for the detailed explanation
old method still requires the fix - good to know you have updated it :+1:

p.s. feel free to close the issue in case you don't plan any further updates - thanks!


Yarn copilot

Ⅰ. Describe what this PR does

yarn copilot code, containers copilot http server and node manager operator

Ⅱ. Does this pull request fix one issue?

fixes #1306
Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist

[ ] I have written necessary docs and comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in make test

close since it is duplicated


When to start and stop

If I want to listen to connection changes throughout the entire lifetime of my app from app delegate, should I stop when app goes into the background, then start again on coming into the foreground?
Or should I just start listening once in app did launch and never start and stop again?
Trying to figure out what's best for battery life and efficiency

use app delegate method applicationWillResignActive to stop and applicationWillEnterForeground to start


Bump sharp to 0.29.0

sharp versions prior to 0.29.0 doesn't support Apple Silicon.

https://github.com/lovell/sharp/issues/2794#issuecomment-900360023
Sharp: Installing: Apple M1

This PR bumps sharp to ^0.29.0.

Ps: yarn test is failing, but I can't run it without bumping, so I don't know if it was failing already.

Thanks for this. The pnpm lockfile would probably need to be updated too, though. The unit test wasn't failing before, but it has to do with the non-ideal way I mocked in that unit test and I think I know what the fix is. I can push a commit for both of those.

You rock, Chris.


[WIP] Enhance Traceflow IPv6 e2e test

/test-all
/test-ipv6-all
/test-ds-all

/test-all
/test-ipv6-all
/test-ds-all

/test-ipv6-only-all

/test-ipv6-only-all

Codecov Report

Merging #1774 (4650021) into master (9d3d10b) will decrease coverage by 6.52%.
The diff coverage is 60.49%.

@@            Coverage Diff             @@
##           master    #1774      +/-   ##
==========================================
- Coverage   63.31%   56.79%   -6.53%
==========================================
  Files         170      192      +22
  Lines       14250    16358    +2108
==========================================
+ Hits         9023     9290     +267
- Misses       4292     6076    +1784
- Partials      935      992      +57

Flag
Coverage Δ

kind-e2e-tests
41.62% <45.67%> (-13.77%)
:arrow_down:

unit-tests
42.71% <37.53%> (+1.44%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

.../agent/apiserver/handlers/networkpolicy/handler.go
58.33% <ø> (ø)

...gent/controller/noderoute/node_route_controller.go
45.83% <0.00%> (-0.64%)
:arrow_down:

pkg/agent/flowexporter/flowrecords/flow_records.go
81.81% <ø> (-7.93%)
:arrow_down:

pkg/agent/interfacestore/types.go
72.72% <ø> (-7.28%)
:arrow_down:

pkg/agent/nodeportlocal/k8s/annotations.go
0.00% <ø> (ø)

pkg/agent/nodeportlocal/k8s/controller.go
0.00% <ø> (ø)

pkg/agent/nodeportlocal/npl_agent_init.go
65.62% <ø> (ø)

pkg/agent/nodeportlocal/portcache/port_table.go
0.00% <ø> (ø)

pkg/agent/nodeportlocal/rules/iptable_rule.go
0.00% <ø> (ø)

pkg/agent/nodeportlocal/rules/rules.go
0.00% <ø> (ø)

... and 149 more

Codecov Report

Merging #1774 (4650021) into master (9d3d10b) will decrease coverage by 6.52%.
The diff coverage is 60.49%.

@@            Coverage Diff             @@
##           master    #1774      +/-   ##
==========================================
- Coverage   63.31%   56.79%   -6.53%
==========================================
  Files         170      192      +22
  Lines       14250    16358    +2108
==========================================
+ Hits         9023     9290     +267
- Misses       4292     6076    +1784
- Partials      935      992      +57

Flag
Coverage Δ

kind-e2e-tests
41.62% <45.67%> (-13.77%)
:arrow_down:

unit-tests
42.71% <37.53%> (+1.44%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

.../agent/apiserver/handlers/networkpolicy/handler.go
58.33% <ø> (ø)

...gent/controller/noderoute/node_route_controller.go
45.83% <0.00%> (-0.64%)
:arrow_down:

pkg/agent/flowexporter/flowrecords/flow_records.go
81.81% <ø> (-7.93%)
:arrow_down:

pkg/agent/interfacestore/types.go
72.72% <ø> (-7.28%)
:arrow_down:

pkg/agent/nodeportlocal/k8s/annotations.go
0.00% <ø> (ø)

pkg/agent/nodeportlocal/k8s/controller.go
0.00% <ø> (ø)

pkg/agent/nodeportlocal/npl_agent_init.go
65.62% <ø> (ø)

pkg/agent/nodeportlocal/portcache/port_table.go
0.00% <ø> (ø)

pkg/agent/nodeportlocal/rules/iptable_rule.go
0.00% <ø> (ø)

pkg/agent/nodeportlocal/rules/rules.go
0.00% <ø> (ø)

... and 149 more

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-networkpolicy

/test-networkpolicy

/test-windows-conformance

/test-windows-conformance

Do you mean we allow both ipHeader and ipv6Header are provided?

Failure if create Traceflow with ipHeader and ipv6Header

Yes, but this is to fix an existing issue.
In types.go, the definition is:
type Packet struct {
	IPHeader        IPHeader        `json:"ipHeader,omitempty"`
	IPv6Header      *IPv6Header     `json:"ipv6Header,omitempty"`
	TransportHeader TransportHeader `json:"transportHeader,omitempty"`
}

Which means if we use this code to create a Traceflow CRD, the IPHeader will ALWAYS exist.
It is dangerous to change the IPHeader type to *IPHeader because all references must be modified to avoid nil pointer panic.
Thus we remove the
                  not:
                    required: ["ipHeader", "ipv6Header"]

verification in CRD to fix the issue.
If ipv6Header exists, the ipHeader will be ignored.

Do you mean we allow both ipHeader and ipv6Header are provided?

Failure if create Traceflow with ipHeader and ipv6Header

Yes, but this is to fix an existing issue.
In types.go, the definition is:
type Packet struct {
	IPHeader        IPHeader        `json:"ipHeader,omitempty"`
	IPv6Header      *IPv6Header     `json:"ipv6Header,omitempty"`
	TransportHeader TransportHeader `json:"transportHeader,omitempty"`
}

Which means if we use this code to create a Traceflow CRD, the IPHeader will ALWAYS exist.
It is dangerous to change the IPHeader type to *IPHeader because all references must be modified to avoid nil pointer panic.
Thus we remove the
                  not:
                    required: ["ipHeader", "ipv6Header"]

verification in CRD to fix the issue.
If ipv6Header exists, the ipHeader will be ignored.

So, I think finally we still like to change IPHeader to *IPHeader?

So, I think finally we still like to change IPHeader to *IPHeader?

So, I think finally we still like to change IPHeader to *IPHeader?

Yes, but this change will affect all references.
Added explanation in this PR.

So, I think finally we still like to change IPHeader to *IPHeader?

Yes, but this change will affect all references.
Added explanation in this PR.

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-all
/test-ipv6-all
/test-ipv6-only-all

Yes. Added explanation in this PR.
Please make sure it is included in the commit message when you merge.

Do you think we can move to *ipHeader in this PR? I think this will affect Traceflow controller, octant UI and external references.
I think you should make the change sometime, but you should change all clients together. I am fine if you like to make another PR for that.

Yes. Added explanation in this PR.
Please make sure it is included in the commit message when you merge.

Do you think we can move to *ipHeader in this PR? I think this will affect Traceflow controller, octant UI and external references.
I think you should make the change sometime, but you should change all clients together. I am fine if you like to make another PR for that.

E2e cases LGTM except for the nits.
It will be better if code can be reused for one case in IPv4 and IPv6. But it doesn't seem easy and cases look more straightforward now when debugging a failed case.

E2e cases LGTM except for the nits.
It will be better if code can be reused for one case in IPv4 and IPv6. But it doesn't seem easy and cases look more straightforward now when debugging a failed case.

I think the code should be reused for IPv4 and IPv6 such as I worked in this patch, but the cases should not be reused because we may want to add some cases for "error" in future.

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-ipv6-e2e
/test-windows-networkpolicy

Could we add a placement comment in the Packet struct, about changing IPHeader to *IPHeader?

Sure. Added TODO in Packet struct.

/test-all
/test-ipv6-all
/test-ipv6-only-all

/test-windows-conformance
/test-windows-networkpolicy