Applications page fix

Added all the available fields/columns from the /get-documents route (except "annotated" because I'm not sure what that is and it was "true" for all rows/applications), fixed some key errors on the page, added ellipses in the filenames so the text isn't crossing into other cells.

Importantly, on the ApplicationsForm page, it was throwing an error if /get-application-questions returned a SERVER_ERROR, causing the website to crash, so I added error handling:

I'm not sure why this application form doesn't work. It was the first row in the applications table. Some forms work though, like this one (second row in applications table):

Thank you Jaccckkiiie


Emoji nits

[ ] Add Emoji reacts for talks (thumbs up, clap, heart). Send as JSON messages in Twilio.
[x] Emoji renderer should never show "undefined" (try typing e.g. :shrug:)

I think this is done now?

The first part still needs to be done, the second is done (and you get 👍 too)

Emoji reactions are completed, and there's also now an emoji picker for text entry


How to change logo ?

Hello, Is it possible to change the top left logo on the swagger page ?
Thanks for this code.

Hello, I'll take a look later. Have not asked this question


How to get Embedding used token?

const { OpenAIEmbeddings } = require("langchain/embeddings/openai");

const embedModel = new OpenAIEmbeddings({
  openAIApiKey: _apiKey,
});

const vectorStore = await HNSWLib.fromDocuments(docs, embedModel);

const dir = Utils.createDir(id, md5Name);
const vectorDir = path.join(dir, "vector");
await vectorStore.save(vectorDir);

The above code uses OpenAIEmbeddings to store docs into HNSWLib. How to obtain the token consumed in this process?

This currently isn't supported but would be good to look into.

It would be very useful to have a callback for embeddings response data in general! Is there any news on this @jacoblee93 ?

I think there was a PR a while back but it never got consensus - what's the use case for you?

Thanks for getting back so quickly! We're keeping track of the cost of embeddings on a user basis. Currently we're estimating the cost, which works well enough, but ideally we would of course use the usage data that OpenAI send in their embeddings response.
We're thinking about writing our own Embeddings class to allow us to pass a callback which can process the entire embeddings response, but we're not entirely sure about the exact behavior.


New index syntax yields Typescript errors

Hi, I'm upgrading from an older version of orchid-orm (1.17.19) to the latest (1.35.0) and when attempting to migrate code to the new index definition syntax on my base table, I always get the following typescript error:

I've tried the most basic version of the function call, and while my intellisense recognizes the t.index function, no structure of inputs seems to get me past this error. Any help would be much appreciated thank you!

False alarm! This turned out to be due to an outdated version of orchid-orm-test-factory that was pinning down orchid-orm-schema-to-zod which was causing an error in my base table. All is good now, thanks for the great library :)


Fix bug in example script

Docs Build status updates of commit 7c26c31:
:clock10: Full build: the average full build time is 17 min(s) 37 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit 7c26c31:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

teams/teams-ps/teams/New-CsBatchPolicyAssignmentOperation.md
:white_check_mark:Succeeded
View (teams-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

@Kateyanne Please merge this PR. Thanks

Docs Build status updates of commit ead286f:
:clock10: Full build: the average full build time is 17 min(s) 37 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit ead286f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

teams/teams-ps/teams/New-CsBatchPolicyAssignmentOperation.md
:white_check_mark:Succeeded
View (teams-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


replaced semicolon with comma

Learn Build status updates of commit 567280f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

powerapps-docs/maker/data-platform/EnvironmentVariables.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

Learn Build status updates of commit 15749cf:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

powerapps-docs/maker/data-platform/EnvironmentVariables.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@rafche - Since the semicolon is separating two complete clauses in the sentence either a comma or a semicolon is suitable in this context. Closing without merging.


feat(terraform): add ASG wait for capacity timeout

The time it takes to spawn instance on the ASG is dependant on a number of factors, and one can hit this Terraform error:
Error: waiting for Auto Scaling Group (kv-server-prod-0-instance-asg) capacity satisfied: timeout while waiting for state to become 'ok' (last state: 'want at least 4 healthy instance(s) in Auto Scaling Group, have 0', timeout: 10m0s)

  with module.fledge_dsp_kv_server.module.autoscaling[0].aws_autoscaling_group.instance_asg,
  on .terraform/modules/fledge_dsp_kv_server/production/terraform/aws/services/autoscaling/main.tf line 64, in resource "aws_autoscaling_group" "instance_asg":
  64: resource "aws_autoscaling_group" "instance_asg" {

Adding this parameter aims at offering more flexibility for end-users.

Thanks for the improvement PR! If you could sign the CLA we'd be happy to take the change. Btw we're still improving our release flow - currently your name in the commits can be overwritten by newer releases. We're working to fix that.

@peiwenhu sorry for the delay! The CLA is signed :)


SOLR-15582: Replace deprecated Tuple API use in SQLHandler.

https://issues.apache.org/jira/browse/SOLR-15582

@joel-bernstein and/or @thelabdude - perhaps you'd be interested in reviewing this small change?


Error in onMessage page?

Request type

[ ] Please close this issue, I accidentally submitted it without adding any details
[ ] New documentation
[x] Correction or update

Details

This page implies that the second argument to onMessage, the sender object, is always of type MessageSender, but that doesn't seem to be the case anymore. If a message is sent to the runtime from the popup of a page action button with this code using browser.runtime.sendMessage(), then the sender object, on Firefox 71, looks like this:
{
  "id"<EMAIL_ADDRESS>  "url": "moz-extension://f4e1d77d-959c-4009-8bbd-d82a27aed1e3/popup/index.html",
  "envType": "addon_child",
  "extensionId"<EMAIL_ADDRESS>  "contextId":<PHONE_NUMBER>26
}

This does not fit the schema described in the MessageSender docs, which doesn't mention the envType or contextId fields, and which describes a field called id which seems to be called extensionId in practice.

Relevant page: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/onMessage

@rebloor I just noticed this issue and envType, extensionId and contextId are properties only used internally (as part of the WebExtension framework's messaging internals), they are not part of the schema and they should ideally not be send to the extension.
In my opinion we should not document them explicitly as part of the API reference (on the contrary it may be more reasonable to file an issue on bugzilla to look into removing them from the data sent to the extension code), they are an implementation detail that is subject to change and we should not suggest the extension developers to use them.

Thanks, @rpl, do you concur @chrisdavidmills? Should I raise the Bugzilla to remove these items? Or do we need to consult with anybody else?

@rpl knows this stuff much better than I do ;-)

@rpl Sorry for the delay on this one, I've now created 1628178.
@chrisdavidmills Are you happy for me to close this one, as it is not a documentation issue?

@rebloor , yup, let's close.

My 50¢. As people likely log this on occasion the API documentation on developer.mozilla.org should include some note about them until they are removed.
As it is now; seeing the properties one are likely to navigate to the runtime.MessageSender documentation looking for what they are – only to find nothing about it. Perhaps double checking if one are looking at the correct object in the documentation, checking code once more, then search the web for why and what it is - only to (hopefully) find that it should not be sent, but it is … i.e. this or linked bug.
That's a rather long and messy route for something that could be stated with one simple sentence in the API documentation.
E.g. at bottom of Type after tlsChannelId, something in the direction of:
- Note: other properties might be present, but these are for internal use, can change or be removed at any time and should not be used. [#BUGNR]


suggestion: allow non-default exports and multiple exports from islands

I think it would be really nice if non-default exports from islands were islands as well (instead of the components they are treated as now). This would also allow fresh component libraries to do something like this:
// Mid component library example
// ./islands/mid.tsx

export * from "https://deno.land/x/mid/mod.ts";

Consumers could then do something like
import { Button } from<EMAIL_ADDRESS>
export default function Home() {
  return (
    <>

        <title>Demo</title>

      <Button>Hey!</Button>
    </>
  );
}

So you want something like this to work?
import { useSignal } from "@preact/signals";
import { CounterOne, CounterTwo } from "../../islands/MultipleCounters.tsx";

export default function Home() {
  return (

      <CounterOne id="counter1" count={useSignal(3)} />
      <CounterTwo id="counter2" count={useSignal(10)} />

  );
}

and
import type { Signal } from "@preact/signals";
import { IS_BROWSER } from "$fresh/runtime.ts";

interface CounterProps {
  count: Signal<number>;
  id: string;
}

export function CounterOne(props: CounterProps) {
  return (

{props.count}

      <button
        id={`b-${props.id}`}
        onClick={() => props.count.value += 1}
        disabled={!IS_BROWSER}
      >
        +1
      </button>

  );
}

export function CounterTwo(props: CounterProps) {
  return (

{props.count}

      <button
        id={`b-${props.id}`}
        onClick={() => props.count.value += 1}
        disabled={!IS_BROWSER}
      >
        +1
      </button>

  );
}

Ok, thanks for confirming. I somehow got this working. I'll clean up the code and get it up for review tomorrow. Not sure if this is even the direction we want to go in, though.


Investigate py27 failure

Sticking at nbconvert 5.3.1 rather than moving to 5.4 fixes the py27 build. Not suggesting this change should be merged, just recording what I found - I'm currently out of time to investigate any further.

Note: not the only thing I've worked on that's had some trouble going from nbconvert 5.3 to 5.4 - see also https://github.com/pyviz/nbsite/issues/84.

xref #15

py27 test is passing (see #33).


add average function

Signed-off-by: Albin Antony<EMAIL_ADDRESS>

@galsalomon66 Please review

why using float for count?

Because, average result might be a floating point number. And that will be lost if we divide by an integer. So, dividing by a floating point number implicitly converts to a decimal number.

I didn't notice that--I'd declare count normally and divide by type(count)?  But also, I had noticed the use of float and wondered why float rather than double?  What is the general thinking around floating point results in the engine?

I didn't notice that--I'd declare count normally and divide by type(count)? But also, I had noticed the use of float and wondered why float rather than double? What is the general thinking around floating point results in the engine?

Will use double. Thanks.

Modified @galsalomon66 @mattbenjamin

I didn't notice that--I'd declare count normally and divide by type(count)? But also, I had noticed the use of float and wondered why float rather than double? What is the general thinking around floating point results in the engine?

should use value object (it handle all s3-select types and operations) ,
what is probably missing is operator override for /


Make adjustable width of resource browser

Context
The width of resource browser is constant now and in some cases there is a lot of space unused.

Idea
Make the width manually adjustable so the user can change it by dragging.

I found no easy way to do that.


See other players mass

anyone tested ?

works

works

merge conflict

You reply too late, i will make again


All text in h1

When reading a file, instead of putting it in paragraphs, it puts the whole text in <h1> instead.

I updated and now all function is working as well.

finally completely solved the problem 100% fully works now :)


Feature Request: Disable pulling the latest image.

Feature Request:
Make it possible to disable pulling the latest docker image.
This to avoid running in to the daily pull limit on docker hub...
Alternatively make it possible for the role to continue if getting the latest images fails.

@kristvanbesien https://github.com/linux-system-roles/podman/pull/82


Update chainlist health-check script

This issue will resolve https://github.com/Koniverse/SubWallet-Extension/issues/2434 as well

resolved in https://github.com/Koniverse/SubWallet-Extension/issues/3243


Godot Linux mint game window very small

I am using Godot 3.2.3 . I am running Godot on Linux Mint 20 Cinnamon with Cinnamon version being 4.6.7. I am using Ge-force GTX 1660 SUPER, NVIDIA 440 driver. All of my projects have a very tiny window when ran. This includes new windows.

@John0456 Do you have an hiDPI display? What's the screen resolution of the PC you're using?
Linux (with X11) does not have a fallback system for applications that don't handle hiDPI support themselves. This means such applications will appear as tiny on hiDPI displays.

I have Acer Technologies 22 G226HQL and a dell sp2208wfp, and according to online datasheets and an online calculator, the dpi for my Acer is 333 DPi and 341 DPI for my dell monitor.

@John0456 There's the culprit :slightly_smiling_face:
You have two solutions here:

Increase your project's Test Width and Test Height settings so the window is larger when you run the project from the editor.
Enable Fullscreen in the Project Settings.

In any case, make sure to enable Display > Window > Dpi > Allow Hidpi to avoid issues on other platforms. Also, you need to configure your project to support multiple resolutions for the solutions above to work correctly.

Test height does not change the height of the window and I would like to be able to test my game without using fullscreen

For some reason changing the Test Height does not affect the the window when ran. Is it possible there is another problem?

@John0456 Did you disable Resizable in the Project Settings? It most likely won't work if it's disabled.

No I did not disable it. A fix that I have discovered is that I can change the monitor size to be in DPI mode. when I do this the game runs as normal but all of my system UI is strange

For some reason after changing the DPI settings it started working again.


Better document for DeprecationLogger

This closes https://github.com/gradle/gradle-private/issues/2432
Previously DeprecationLogger is not well documented, developers have to run a build to
see what the final message looks like. This commit adds clear documentation for each method.

Thanks @wolfs !


Pass in false to remove option

If we do not want the firstText, will it be nicer to pass it a false value to totally remove it?
Like:
<PaginationBox firstText={false} lastText={fasle} />

Also I am puzzle on why angularLink for a react component, hmms...

This a good idea:

I add this in next reliz. Thanks.

And i check angularLink props.

Sorry did not read carefully, it was done by using edgeLinks. Close it now!


ENH: Adds CyclicLR

Closes https://github.com/dnouri/skorch/issues/168.

Adds on_batch_begin to LRScheduler to step through CyclicLR. This uses len(net.history[-1, 'batches']) to get the batch index for the current epoch. Once there are more than one epoch, the total number of batches per epoch is obtained by len(net.history[-2, 'batches']) .
CyclicLR is a subclass of _LRScheduler which allows for LRScheduler(CyclicLR).
Tests were refactored a little to use @pytest.mark.parametrize. Additional tests were added to confirm that LRScheduler is calling step or batch_step  the expected number of times.

This looks like a great addition. Also thanks for improving the tests. I will have a more thorough look at it soon, but I noticed one thing right away: Would you mind changing the docstring to numpy style, like in the rest of skorch? Thank you

I just updated this PR with the following changes:

Converted CyclicLR's docstring to numpy style.
Adds __all__ to callbacks/__init__.py so that sphinx's automodule: skorch.callbacks can detect the docstrings.
Fixes most warnings from sphinx doc generation.

Thank you for the amendments.
I have a question regarding usability. Currently, a lot of work in CyclicLR and WarmRestartLR is done during __init__. My proposal is to move that to the initialize method of the callback instead (while saving the parameters as they come during __init__). This would have two advantages in my opinion:

It works better with set_params(...). This method does not use __init__, so all the work done in __init__ (such as parameter validation) would be skipped. Therefore, the change would prevent users from setting parameters via set_params that cause trouble even though they work during __init__. set_params is used for things such as GridSearchCV.
The change would allow us to leave the optimizer parameter to be None when initializing the callbacks. The callback would then take the net's optimizer during callback.initialize (something we would need to add). This is more user friendly, since typically in skorch, we don't have an initialized optimizer at the time we instantiate the callbacks, making the current usage slightly awkward.

The proposed changes would allow code like this to work:
net = NeuralNetClassifier(
    MyModule,
    callbacks=[CyclicLR(optimizer=None)],
)
net.fit(X, y)

(We would still allow to pass the optimizer explicitely.)
We can always implement these changes at a later stage. My question is rather whether you see a problem with that.

It feels like skorch likes to have LRScheduler be the user facing interface for LR scheduling, i.e.:
net = NeuralNetClassifier(
    MyModule,
    callbacks=[LRScheduler('CyclicLR')],
)
net.fit(X, y)

Nevertheless, I think it is a good idea to move the following lines in LRScheduler:
https://github.com/dnouri/skorch/blob/218716e0631ab33c820562a8b18c60380ba0f6ff/skorch/callbacks/lr_scheduler.py#L46-L49
to the initialize callback. This would require the optimizer to be initialized before the callbacks are initialized. The order of initialization is defined here:
https://github.com/dnouri/skorch/blob/218716e0631ab33c820562a8b18c60380ba0f6ff/skorch/net.py#L428-L440
We would need to move the self.initialize_optimizer() call before the self.initialize_callbacks(). Is there any issue with changing the order of initialization?

There are two places where _LRScheduler stores state:

It uses last_epoch to remember the last epoch. LRscheduler avoids using this internal state by always passing in the current epoch to the step function.

It stores initial_lr in optimizer.param_groups, this must be done once when the last_epoch parameter is -1. My latest updates uses net.history to get this information and passes it along.

All other parameters are stored in LRScheduler's kwargs which works with set_params. With the latest updates, I think leaving the initialization in on_train_begin is okay, and we won't need change the callback.initialize interface.
I made a few more additional tweaks:

The accuracy score in test_net_learns went to 0.693 so I lowered the test from 0.7 to 0.65. The test_net.py tests does not use LRScheduler, so this was a bit strange.
I converted CyclicLR to not be a subclass of _LRScheduler just like how ReduceLROnPlateau is not a subclass. A user would have to pass in the strings: "CyclicLR" or "ReduceLROnPlateau" to LRScheduler to use them.

Hi Thomas,
Thanks for putting so much thought into this PR. I will probably not have the time to review your changes this week, but will start next week as soon as possible. I hope that's okay.
Cheers,
Benjamin

I have updated the PR with your suggestions!

This PR is updated with @ottonemo's suggestions.

thx @thomasjpfan


Print stacktrace

Sometimes exception messages are useless e.g. Expected a value of type 'String', but got one of type 'Null'

Printing entire stack trace may result verbose, maybe we should make this optional?

That's good idea. How name the option? What do we name this property? verbosity printStacktrace stacktrace includeStacktrace

I think printStacktrace it is the most intuitive! Would you mind adding it? otherwise I can do it on the weekend!


Sync version with Glutin?

I don't know if it's just me, but I find it confusing that the version of winit (0.17.x) and glutin (0.18.x) are off by one. Could they be synced on the next breaking change, so that winit 0.19 is a dependency of glutin 0.19?

 Pro: They are frequently updated in lock-step anyway, so users might have an easier time figuring out and specifying the correct dependencies.

 Con: If there was a breaking change in only one of winit or glutin that does not require a corresponding change in the other, the locked version bump might not be strictly necessary as per semver.

On the other hand I think that documenting and (as dependencies) specifying a range of (in fact) compatible versions in this case should be easy enough.
Example
To demonstrate the case where winit 0.20 and 0.21 were breaking changes, but glutin 0.20 and 0.21 just bumped version in tandem.
Glutin docs:

Glutin version 0.21 is backwards-compatible with versions 0.20 and 0.19.

User dependencies:
[dependencies]
glutin = ">= 0.19.4, < 0.22"
winit = "0.21.1"

What do you think?

(For the colors above see https://stackoverflow.com/a/41247934.)

While I agree that the differing version numbers aren't pretty, it feels silly to me to artificially force them to match. For one thing, I feel it's more in the spirit of the Rust philosophy to have version numbers be transparent and explicit. (The other big concern is that it's more hassle for me to coordinate releases!)
The reason releases tend to happen in lockstep is because glutin gets almost no activity, i.e. after I merge tomaka/glutin#1029 a new glutin release will probably be made. If versions were synchronized, then winit would have to bump ahead by two versions, which would be confusing to anyone using winit without glutin (of which there are increasingly many).
On that same note, you could say that any other context crates that use winit should be synchronized... winit and glutin aren't really married; they just happen to spend a lot of time together. The fact that the current version numbers are only off by 1 is a coincidence, which I think belies how much they're able to progress separately.

Sounds good to me. Unless there is a huge crowd in favor of my proposal showing up very soon, then this can be closed :)

It's worth noting that cargo supports non-exact dependencies. Once winit hits 1.0, it may be worth setting glutin's winit dependency to be ~1 so that we no longer have to manually update glutin's dependencies.

@Osspial Note that my issue was about the user of glutin and winit having to specify different versions for each, while your comment seems to be about glutin specifying its dependency on winit.
But now reflecting on it (coming from the issue comment linking to glutin docs section that originates from winit docs...) my / this issue might be resolved by the user just using glutin and using any winit functionality via what glutin re-exports.

Another issue with this is that, while glutin is perhaps currently the most popular downstream user of winit, winit was separated from glutin in the first place in order to support other graphics backends. For example, the vulkano org have a crate that allows for using a vulkano instance within a winit window and has nothing to do with glutin at all. If winit was designed solely for glutin I think I'd consider this more closely, but I don't think it makes a great deal of sense as winit isn't inherently tied to glutin (even if glutin is tied to winit). Thanks for the issue regardless @felixrabe!

this issue might be resolved by the user just using glutin and using any winit functionality via what glutin re-exports.

Yes I believe it is glutin's goal to re-export everything from winit that could be needed by a downstream user. If you're missing access to something in winit through glutin, an issue would be very welcome at the glutin crate!


install.sh does not work.

It gets stuck at wget, it's not even a command for me, I updated install.sh in PR #18.

PR #18 fixes this issue

Now #23 will fix this...


v2.0.0-Release <- Read this for performance problems

This was originally a PR here, but has been transformed into an issue due to being pin-able

what has been done?
We are hard at work improving Uptime Kuma.
If you want to have a look at the full set of features for v2.0, have a look here.
Most notably this includes (a full migration guide will be made before the release, dont worry):

better performance through external MariaDB, storing heartbeats in an aggregated form, full server-side pagination for important events, better async and database usage
=> even though benchmarking is still out, we are confident that this pushes the prominent "limits" (highly hardware-dependent, not a limit imposed by us) ~500 Monitor or ~1.5GB DB-size
A large part of the focus in this release is on performance. We don't know if we are optimising for the right thing, see #4456 for a discussion on this topic.

[!TIP]
If you are affected by the performance problems of v1, you need to reduce the amount of data you store.
The core problem is that Uptime Kuma in v1 has to do a table scan of the entire heartbeat table for some operations.
The solution boils down to having a lower amount of data => making Uptime Kuma less worried about reading those gigabytes of data.:

reduce the retention and execute a manual cleanup via the VACUUM button under /settings/monitor-history
Increase the time between checks
pause or reduce the amount of monitors
delete the specific history of less essential monitors (to "lower" their retention below the configured maximum)

tightening the security via offering rootless docker images images #2086 #4052
deprecated backup feature has been dropped (see https://github.com/louislam/uptime-kuma/pull/3892#issuecomment-1949941292 for an explanation why)
deprecated cacheable lookups (not the same as nscd) have been dropped #3762
A lot of bugfixes, some minor new features (see the milestone)

what is needed to get 2.0.0-beta.0 released

[!NOTE]
We hope 2.0.0-beta.0 can be released in spring 2024, which doesn't include the e2e tests yet. During the beta test, we will try to work on implementing the e2e tests.

[!TIP]
How can I get involved?
While most of the bugs noted below require reading some code
=> gaining some context about how the aggregated tables work, some work do not and are such better starting points:

writing a synthetic benchmark which spawns some monitors and looks how the server handles it
helping in writing e2e tests using playwright

some features have not adopted to new aggregate tables yet

[ ] Migrate existing heartbeat data into aggregate tables
[x] Clear stats (#4324)
[ ] History retention
[x] Ping chart (#4264)
[ ] ~Heartbeat table keeps 24-48 hours data only (excepted for important events, it will keep longer for the event list)~ (Can be deferred)
[x] Test and fix the Badges feature (originally introduced in #1119, a big headache for us right now because the new table schemas break this feature a lot) (https://github.com/louislam/uptime-kuma/pull/4850)

[ ] Testing

[x] https://github.com/louislam/uptime-kuma/pull/2174
[x] https://github.com/louislam/uptime-kuma/pull/3893
[ ] Write more E2E Testing using Playwright

[ ] Document how the aggregated tables work for our contributors in our contribution guide
[ ] Migration guide from v1 to v2 (Wiki) https://github.com/louislam/uptime-kuma-wiki/pull/53

[ ] New Docker tags
[ ] Notify about breaking changes and write a migration guide

removed variable badges
SMTP-templating #3414

dropped support for vArIaBlE Cased variables
deprecated UPPERCASE variables (this was added to make the v1⇒v2 migration more seamless, but will be removed in v3)

removed deprecations:

#3762
#3892

https://github.com/louislam/uptime-kuma/pull/4289
default retires is now 0 instead of 1

[ ] Benchmark where the new performance limits are
[ ] Write the changelog and Release 2.0.0-beta.0

is version already installable at the moment, or there are many things yet to be done to make it so and for a pre-release

@compgeniuses
Our installation guide only works for stable versions (it checks out a git tag to avoid users being on the wrong branch in npm run setup).
Pre-releases will be made once we don't have glaring bugs left, see my post above for which ones there are.
If you want to test-drive or contribute one of the areas named above, our contribution guide should have all the answers. If you are missing something for development, feel free to ping me.
We also have this way of testing PRs: https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests

Uptime kuma supports API call
so we can use Rundeck to set Incidents on it and once it resolves we can stop the incident
is that possible?

This is an discussion issue. Please ask help-quesstions via the appropirate means to not spam everyone who subscribes to this thread

Uptime kuma supports API call

Currently, we don't have an official API. Please refer to my answer to you here https://github.com/louislam/uptime-kuma/issues/118#issuecomment-1994429676

How is it going?

I think you are asking about a status update: The checklist above is kept up to date in what needs to happen before 2.0.0-beta.0.
Is there something that we are missing in the post?

No I don't think so. But I am more interested in knowing if the beta is still estimated during the spring now?

We don't give out concrete deadlines and prioritise long-term team health over achieving short-term goals.
=> Maybe. See #noestimates why we don't give out more concrete timelines rather than "Spring" (=a flexgoal).
Being cheeky: If you want to move this along, you could consider contributing...

What is the best way to try this out? We deploy via Docker on Railway.app and we use it to monitor our services. It is pretty low-stakes environment and I am happy to risk running a preview version of Uptime Kuma to get access to the new features and 'test run' it. But since it is not available on Docker hub I am not sure how to get started

What is the best way to try this out? We deploy via Docker on Railway.app and we use it to monitor our services. It is pretty low-stakes environment and I am happy to risk running a preview version of Uptime Kuma to get access to the new features and 'test run' it. But since it is not available on Docker hub I am not sure how to get started

U can do this by not using docker but by running in nodejs environment. Read the README

What is the best way to try this out? We deploy via Docker on Railway.app and we use it to monitor our services. It is pretty low-stakes environment and I am happy to risk running a preview version of Uptime Kuma to get access to the new features and 'test run' it. But since it is not available on Docker hub I am not sure how to get started

U can do this by not using docker but by running in nodejs environment. Read the README

Thanks - is it just the master branch? I couldn't find a specific branch or tag for v2.

In master, development happens for v2.0-dev.
We currently have NOT published a git/docker tag as we are NOT ready to have a public beta (see the checklist above)
You can:

Test PRs via the path listed here
help developing using the path laid out in our contribution guide
subscribe to this issue or to releases to get notified of the beta once it releases

[!NOTE]
If you want to use uptime kuma in any production environment, please refer to our installation guide.
We do not offer stability/semver guarantees for development versions such as v2.0-dev.

@CommanderStorm
I would like to take care of testing activity
Backend tests are stored in test/backend-test and Frontend tests are stored in test/e2e AFAIK
Can you help me with lists of tests that are to be written and documentation/examples of how they are to be written and tested

I am currently quite busy with uni stuff (I have a thesis deadline on Saturday) and I will get back to you on what is necessary precisely and on the code examples:
From the api side, I think these things need a test case:

the badges API does work
some of the other apis likely also benefit from testing, but would need to look into them

I think the most beneficial would be a frontend end to end test of interacting with monitors:

logging into the ui, adding a monitor
seeing that the monitor does a ping
enacting a maintenance period
seeing that the monitor is in maintenance
adding it to a status page

Fom the initialisation side (bit trickier):

launching (fresh) via maridb works
launching (fresh)
migrating from one to the other works (don't think that we have yet looked into this)

From a monitor perspective (not related to v2.0, but to be complete):
Most of our monitors are currently untested. At least some of the bug reports are likely due to this.
My longer term plan is to use test containers to verify the monitors work as intended. I have currently not been able to finish the debugging effort of said PR (it is basically done, but one test case is not working. Will need to debug)
From the notification providers (not related to v2.0, but to be complete):
Our current testing strategy is to require screenshots of the relevant events by our contributors. I am unsure if we can test this better, but am open to ideas ^^

We don't give out concrete deadlines and prioritise long-term health over achieving short-term goals. In a volunteer run org, anything else would not be sustainable.
See #noestimates why we don't give out more concrete timelines rather than "Spring"/"Summer" (=a flexgoal).
Being cheeky: If you want to move this along, you could consider contributing ...

I'd like to know if it's possible to have v2 (or nightly docker versions) of this repo published in Docker Hub. If there's any technical constraint for that purpose, I might be able to contribute.

I'd like to know if it's possible to have v2 (or nightly docker versions) of this repo published in Docker Hub. If there's any technical constraint for that purpose, I might be able to contribute.

While a good idea, it may end up causing alot of support request that are unnecessary to the community due to incomplete build version.

is there any ETA about v2.0.0 release date?
thanks

See top of this post, the tasklist progress is at 5/17 so still a lot of work todo. This is FOSS so to help speed up improvements, you can contribute in different areas as per your level of expertise. It has been explained several times that no ETA can be given depending on the contributions of the community mainly.

tasklist progress is at 5/17 so still a lot of work todo

That is somewhat misleading.
There are two items left which NEED to happen:

Going through the PRs, writing a changelog and migration guide
Writing a db-migration for the existing heatbeat data into the new, aggregated schema.

literally any help is always appreciated.
Even if just looking at benchmarking/infra/testing, there are lots of bugs to catch (as with most FOSS software).

reduce the retention and execute a manual cleanup under /settings/monitor-history

just to be clear, as i assume this is the best mitigation: after setting a lower number of retention days, for manual cleanup you intend a "clear full statistic" or "shrink database"? so the retention days are not applied to the previous stored datas?

Cleanup = the VACUUM button

See top of this post

Not even that, have commented somethng similar why we won't give out ETAs multiple times in this thread.. Example: #4500 (comment)

tasklist progress is at 5/17 so still a lot of work todo

That is somewhat misleading. There are two items left which NEED to happen:

Going through the PRs, writing a changelog and migration guide
Writing a db-migration for the existing heatbeat data into the new, aggregated schema.

literally any help is appreciated. Even if just looking at benchmarking/infra/testing, there are lots of bugs to catch (as with most FOSS software).

I've written some code that fetched all the PRs since the latest tagged commit, outputs them into markdown files, adds code diffs, and then generates changelogs using Sonnet 3.5.
Here's some example outputs:
PR #4850
- Fixed uptime & ping badge duration to handle numeric input without units
- Implemented validation to ensure duration input is within allowed range
- Enabled support for different duration units (m, h, d, w, M, y)
- Updated badge label formatting to remove redundant unit suffix

PR #4757
- Bug fix: Corrected a typo in the internal code for handling the file upload icon for the status page.

PR #4728
- Improved MariaDB connection handling by configuring the connection pool with sensible defaults (min: 0, max: 10, idleTimeoutMillis: 30000)
- Addressed the `Error: read ECONNRESET` issue with Knex, which sometimes occurred when connecting to MariaDB

My plan was to then process these outputs again to combine and condense them into a single changelog. I think Sonnet might be capable of writing the database migration and migration guide as well.

Is this helpful?
If so, are there any special requests (formatting, adjustments, or otherwise) before I proceed?

Cleanup = the VACUUM button

Btw, this is a very temporary workaround... i have a 2,7GB (?! or at least is what is saying on the shrink button) database, my history was with no limit and i've set it to 90days (maybe there was a 2y or more history) but:

the cleanup will likely lock all monitors for ~2h than all keep working good for just 2days than the dashboard will be again "unlodable" (monitors/notifications will keep working good)
idk why the database is that big and did not decreased the size after setting a max days monitor history

I've written some code that fetched all the PRs since the latest tagged commit, outputs them into markdown files, adds code diffs, and then generates changelogs using Sonnet 3.5.

My plan was to then process these outputs again to combine and condense them into a single changelog. I think Sonnet might be capable of writing (or assisting to write) a migration guide as well.
Is this helpful?
If so, are there any special requests (formatting, adjustments, or otherwise) before I proceed?

looking sonnet up, it seems to be an ai?
if you're using an ai for a changelog, check that it's actually correct -- which means manually going through each PR.
but more importantly, a migration guide, which can have serious consequences if if's wrong, should never be written with an ai, or other automation.

I've written some code that fetched all the PRs since the latest tagged commit, outputs them into markdown files, adds code diffs, and then generates changelogs using Sonnet 3.5.

My plan was to then process these outputs again to combine and condense them into a single changelog. I think Sonnet might be capable of writing (or assisting to write) a migration guide as well.
Is this helpful?
If so, are there any special requests (formatting, adjustments, or otherwise) before I proceed?

looking sonnet up, it seems to be an ai? if you're using an ai for a changelog, check that it's actually correct -- which means manually going through each PR.
but more importantly, a migration guide, which can have serious consequences if if's wrong, should never be written with an ai, or other automation.

Whoever writes the changelog would have to go through every PR manually anyway. Let's just make sure together that the migration guide doesn't have any errors.

@CommanderStorm  Hello, has a release date been set for the V2 version? If not, when can we expect the V2 version to be available?

https://github.com/louislam/uptime-kuma/issues/4500#issuecomment-2054135888
https://github.com/louislam/uptime-kuma/issues/4500#issuecomment-2201448336

@CommanderStorm Hello, has a release date been set for the V2 version? If not, when can we expect the V2 version to be available?

https://github.com/louislam/uptime-kuma/issues/4500#issuecomment-2054135888
https://github.com/louislam/uptime-kuma/issues/4500#issuecomment-2201448336

Closing as 2.0.0-beta.0 was released

Seems to embedded:
https://github.com/louislam/uptime-kuma/blob/4e144ec71ceb917fd08a1842a5f50538af8e5472/docker/debian-base.dockerfile#L69
I'd love if we could separate this.

personally, I'd prefer to either choose between using the embedded SQL-Lite (which we know the limitations in production, but good enough for a testing environment) OR go full power and leave the user running a separated MariaDB offering the following advantages (to my eyes of course):

UptimeKuma image will be smaller because you won't need to bloat it with mariaDB
Users can have control on the DB and backup is easier, because you just need to backup the volume of the MariaDB container and probably it is beneficial for uptimeKuma developers because, they won't need to think how to backup the DB or implement any feature for this and let the end-users deal with it

To summarize:
I'd add an env variable to uptimeKuma configuration, if it is filled it will use the mariaDB container + port, otherwise it will run with SQL-Lite by default

If you don't want mariadb, please use beta-slim instead.

But in general, the peculiarity of docker is the detachment of dependencies so having an image ALL-IN-ONE is in my opinion against this principle

Having all of the features in the default image and having slim variants is quite common.

@CommanderStorm thanks for the response.
So, if I understood correctly, the slim version uses sql lite or can I pass set a connection to an external mariaDB container?

The slim version can use sqlite or an external mariaDB container

@CommanderStorm
Thanks for the hint, the beta version works like a charm! <3

@louislam , @CommanderStorm ,
I am currently running Uptime Kuma version 1.23.11 without Docker and would like to migrate to version 2. Could you kindly advise which branch I should switch to in order to access the beta/v2 release? Additionally, any guidance on the migration process would be greatly appreciated.
Thank you in advance for your support.

Please refer to https://github.com/louislam/uptime-kuma/wiki/Migration-From-v1-To-v2
If anything is missing, feedback is appreciated

Dear Frank,
I am running Uptime Kuma in a non-Docker environment because I have integrated a custom module into the existing setup and submitted a pull request for these changes.[https://github.com/louislam/uptime-kuma/pull/5382]
To maintain my customizations, I update and manage the application without Docker. So i want to migrate from v1 to v2 without using Docker.
Here are the steps I follow for setup and execution & updates:
Update from git
git fetch --all
git checkout 1.23.15 --force
Install dependencies and prebuilt
npm install --production
npm run download-dist
npm run setup
Option 1. Try it
node server/server.js
Start Server
pm2 start server/server.js --name uptime-kuma
Looking for the migration guide without using Docker.

From: Frank Elsinga @.>
Sent: Monday, December 2, 2024 1:31 PM
To: louislam/uptime-kuma @.>
Cc: Maryam Saleem @.>; Comment @.>
Subject: Re: [louislam/uptime-kuma] v2.0.0-Release <- Read this for performance problems (Issue #4500)
You don't often get email from @.*** Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification
Please refer to https://github.com/louislam/uptime-kuma/wiki/Migration-From-v1-To-v2
If anything is missing, feedback is appreciated
—
Reply to this email directly, view it on GitHubhttps://github.com/louislam/uptime-kuma/issues/4500#issuecomment-2510879160, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BHCBSCYNP3IPPZ2FH756ZEL2DQLGDAVCNFSM6AAAAABDNIX4NKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJQHA3TSMJWGA.
You are receiving this because you commented.Message ID: @.***>

@CommanderStorm , Dear Frank,
I am running Uptime Kuma in a non-Docker environment because I have integrated a custom module into the existing setup and submitted a pull request for these changes.[https://github.com//pull/5382]
To maintain my customizations, I update and manage the application without Docker. So i want to migrate from v1 to v2 without using Docker.
Here are the steps I follow for setup and execution & updates:
Update from git
git fetch --all git checkout 1.23.15 --force
Install dependencies and prebuilt
npm install --production npm run download-dist
npm run setup
Option 1. Try it
node server/server.js
Start Server
pm2 start server/server.js --name uptime-kuma
Looking for the migration guide without using Docker.

You could build your own Docker image with the patch maybe? Unless you really don't wanna use Docker

It sounds like you are looking for a development environment.
We have documented this here: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md
What you are trying to do is otherwise not well supported as it is not the main path.
You can extend it, but make sure you actually have the state as you expect it. Both npm run setup and the git part may reset your changes.
In any case, there is no official support from us for this kind of deployment as I don't have capacity for this.

@CommanderStorm ,
Thank you for your response and guidance.
I wanted to let you know that I have already opened a pull request (PR) to contribute to the project. My goal is to enhance Uptime Kuma by adding SIP-related features, and I fully understand that my deployment method is not the standard approach.
However, I'm currently running Uptime Kuma using PM2 in a Linux environment, not Docker, and I aim to migrate from v1 to v2 without relying on Docker. I realize this isn't officially supported

@Wraaath ,
I’m currently running Uptime Kuma using PM2 in a Linux environment instead of Docker, and my goal is to migrate from v1 to v2 while continuing to use PM2. I prefer not to rely on a custom Docker image with patches for long-term use. However, if creating a custom image is necessary to complete the migration process, I’m open to exploring that option temporarily.
Could you please clarify what specific patch or adjustments you are referring to? Your advice will help me ensure a smooth migration while aligning with the project’s standards.

@msaleemCinnova
Sorry, did not have the time to look into said PR. I am currently quite overloaded with Uni and other work.
Since you already wrote the code, please just post it. Having a discussion is not quite relevant to adding notification providers or basic (cannot be implemented using current monitors) monitors like the one you are trying to add.
I don't know what a SIP is => please preferably include a test case that it works (see the mqtt test cases for examples how this can be done).

@CommanderStorm ,
Thank you for taking the time to respond despite your busy schedule—I completely understand how demanding university and other work commitments can be.
I will add the code to submitted the PR. I’ll respect your preference to keep the process straightforward and will avoid extensive discussions.


Sometimes need some ability to select on which element a child should apply (raised for b.Select and HTMX attributes)

I apologize for the issues if they are bugging you. If you open the GH Disucssions I find those better for code sharing and just general questions.
I am trying to integrate this library with some HTMX functionality. I just noticed  the bulma.select is misbehaving. Well at least according to my current naive understanding of how the library works as well as gomponents.
I think this is because in Bulma the select is wrapped in a div and the hx attribute is being added to the div and not the select element.  The other b. form controls don't seem to have this issue.
Truncated Imports for clarity:

import (

g "github.com/maragudk/gomponents"
hx "github.com/maragudk/gomponents-htmx"
b "github.com/willoma/bulma-gomponents"
"github.com/willoma/bulma-gomponents/el"
)

I have this function that returns a bulma dropdown. I want to add an htmx attribute to the select element. The hx.post is getting added to the div and not the select element which makes sense (sort of).
The hx.Post(RouteAdminQuestionFormPathFull) post is just dropped from the generated HTML.

func (q Question) bulmaAdminAnswerTypeField() b.Element {

	dropDown :=

		b.Field(
			b.Label(
				q.getFieldLabel(answerTypeFieldName),
			),
			b.Control(
				b.Select(
					hx.Post(RouteAdminQuestionFormPathFull),

					b.FullWidth,
					b.Option(answerTypeLongText, getAnswerTypeLabel(answerTypeLongText)),
					b.Option(answerTypeShortText, getAnswerTypeLabel(answerTypeShortText)),
					b.Option(answerTypeEnumerationSingle, getAnswerTypeLabel(answerTypeEnumerationSingle)),

				),
			),
		)

	return dropDown
}

The (truncated for clarity) generated HTML is:
<div class="select is-fullwidth" hx-post="/admin/questions/">
		<select>
				<option value="TextLong">Long Text</option>
				<option value="TextShort">Short Text</option>
		</select>
</div>

The hx-post attribute is being added to the div and not the select element. The documenation for the b.Select do have some mention of this. However, I can't seem to figure out how to add the hx-post attribute to the select element.
If I change the b.Select to a el.Select it does work but I don't get all my nice Bulma Classes that your wonderful library provides with el.Select but I can add those.
The expected HTML Output of the select element is:
<select class="is-fullwidth" hx-post="/admin/questions/">
I may be missing something obvious here.
https://github.com/willoma/bulma-gomponents/blob/0de0750590f703c7cda64a75e03226c3ac392770/form_select.go#L88

Hello,
(regarding the discussions space, this project being fairly new and me being alone on this on my spare time, I prefer having everything in one place. Moreover if something happens at this point in the project, it probably is an issue rather than a simple discussion - at least an issue for the docs).
There is currently no possibility to do this, and it is a problem. Thanks for raising it. It may also apply to other elements.
The most obvious possibility would be to add b.Inner and b.Outer markers in order to allow the developer to chose on which element they want to apply a child, but I would love to have something smarter than this. If you have any suggestion, don't hesitate to share it, I'm open to any idea!

With v0.4.0, you may now simply provide the gomponents-htmx attribute to the bulma-gomponents functions, it will be applied to the <select>.
But you can also use b.Inner(xxx) and b.Outer(xxx) if needed.

I just upgraded to 0.5.0.  I think this issue is regressing. This was working in 0.4.0
Creating an Select with some HTMX triggers on change.
	dropDown :=

		b.Field(
			b.Label(
				q.getFieldLabel(answerTypeFieldName),
			),
			b.Control(

				b.Select(
					b.FullWidth,

					html.Name(answerTypeFieldName),
					hx.Post(q.editPath()),
					hx.Target(hxTargetQuestionCard),

					b.Option(
						answerTypeLongText,
						getAnswerTypeLabel(answerTypeLongText),
						g.If(q.AnswerType == answerTypeLongText, html.Selected()),
						g.If(q.AnswerType == "", html.Selected()),
					),

				),
			),

		)

The name, hx-post and hx-target are being supplied to the outer div and not the select. I might have just missing something in the updated documents.

Oh...gees...now I see it staring at me in the docs.
b.OnSelect
Correct & it works!
dropDown :=

		b.Field(
			b.Label(
				q.getFieldLabel(answerTypeFieldName),
			),
			b.Control(

				b.Select(
					b.FullWidth,
					b.OnSelect(
						html.Name(answerTypeFieldName),
						hx.Post(q.editPath()),
						hx.Target(hxTargetQuestionCard),
					),
					b.Option(
						answerTypeLongText,
						getAnswerTypeLabel(answerTypeLongText),
						g.If(q.AnswerType == answerTypeLongText, html.Selected()),
						g.If(q.AnswerType == "", html.Selected()),
					),

Yes, I struggled to get something working for this one, regarding the default target for children, I may have been better, but OnSelect is your saviour, at list for now :-)


Unable find the video download link

HI bro i am not finding the correct video download link
like         print("Link.....................${e.link}"); code take form readme file.
Thumbnail URL working correctly fine.

Hi @ADEELAHMAD256. What is the URL used and what platform?

Hi @thitlwincoder,
Great package, but it is not consistant.
Im also facing issue package parsing html on low level code is not fetching correct html elements from  where video meta data information can be fetched. See the screen shot of the file social.dart
Your package is not parsing this part of the html:

I tried this facebook link:
https://www.facebook.com/share/v/qGQfwEUtQasJKyPC/?mibextid=jmPrMh

@ADEELAHMAD256 I tried with your given URL. This is a result.

Yes thats the video but the problem is that i am not recieving the meta data in my app, even when the website has generated the data.


Do not perform domain substitutions within comments

Covers C/C++, Java, Javascript and Python file extensions
This change will prevent domain substitutions to happen within comments or comments blocks, thus reducing the amount of unnecessary file changes when applying domain substitution.
This is what I had in mind for issue #849.

I think there's potential for additional processing in the future.

As a general rule I avoid adding code for the "just in case" situation, but if you have some use-cases to leverage already then sure - why not.

For starters, the regex for the non-(Python and GN) files don't apply to all the selected file types.

What do you mean here? I am genuinely curious about some bug I might not have spotted.

Since domain substitution is an essential component, I'd rather play it safe and implement AST parsing.

That would indeed be a very advanced and complete solution.

As a general rule I avoid adding code for the "just in case" situation, but if you have some use-cases to leverage already then sure - why not.

I think the AndroidManifest schema problem is another such example. Also, anything in DOMAIN_EXCLUDE_PREFIXES could have a smarter exclusion rule associated with them.

What do you mean here? I am genuinely curious about some bug I might not have spotted.

Actually, I was mistaken about this. I didn't realize all those languages supported both of those commenting types.
However, I also realized your code will break if the comment delimiter appears in strings. I don't know if any substitutions could be affected by this, though.

However, I also realized your code will break if the comment delimiter appears in strings. I don't know if any substitutions could be affected by this, though.

Yes, I am aware, I decided to go with this risk. I have inspected the produced diff (now much smaller thanks to the code in this PR) a few times (even if not thoroughly) and it seemed correct.

What issue is tried to be solved by not performing domain substitution on comments? If it's the timestamps, wasn't that taken care of in https://github.com/Eloston/ungoogled-chromium/commit/1a0e163a1130c7b47b8a98fc387628b077320a49?

@Luka-Filipovic I create git commits after performing the domain substitutions and there are several MBs of unwanted changes; I also think that changing the timestamp alone won't prevent the file from being rebuilt if one if its comments changed.

@Luka-Filipovic I create git commits after performing the domain substitutions and there are several MBs of unwanted changes;

What percentage of files from lists have links only in comments? Not doing domsub in test files could also help with your problem, and it can be made only by parsing the file name.
When comments and test files are cut out, what could be the next step in improving this process?

I also think that changing the timestamp alone won't prevent the file from being rebuilt if one if its comments changed.

If that's the case (I didn't test it myself yet), would https://github.com/Eloston/ungoogled-chromium/issues/1185 help the problem?

Not doing domsub in test files could also help with your problem, and it can be made only by parsing the file name.

I already covered this by excluding all test files/directories I could identify.

What percentage of files from lists have links only in comments?

Can't say, but if you make a git diff you will not be able to easily identify the actual code changes because the comment changes drown them out.

If that's the case (I didn't test it myself yet), would #1185 help the problem?

ninja uses timestamps like make, there's an open ninja issue about using file characteristics.
The problem is when you build Chromium and then run domain substitution: setting all files to a precedent timestamp to trick ninja into not rebuilding those files is wrong, as you cannot tell if only comments or code were changed. Thus what will happen is that there will be no advantage in building Chromium and then your modified version with patches and domain substitution, as most files will be rebuilt because of the changes. ccache mitigates this to some extent, but it still leaves room for improvement; with the patch I proposed here I made this process of re-using unchanged object files more efficient.
As for #1185 I actually think it's better to apply domain substitution after the other patches, so that they can be used individually without dependencies on the big domain substitution patch (which I treat as a patch, not different from any other).

The problem is when you build Chromium and then run domain substitution: setting all files to a precedent timestamp to trick ninja into not rebuilding those files is wrong, as you cannot tell if only comments or code were changed. Thus what will happen is that there will be no advantage in building Chromium and then your modified version with patches and domain substitution, as most files will be rebuilt because of the changes. ccache mitigates this to some extent, but it still leaves room for improvement; with the patch I proposed here I made this process of re-using unchanged object files more efficient.

That's interesting. What use-case do you have where you'd want to build Chromium once first, apply domain substitution, then re-run the build? I envisioned only these two workflows for domain substitution:

Full build: Domain substitution, then build.
Incremental build:

Apply domain substitution
Build
Revert domain substitution
Make code changes
Repeat steps 1-4 until the the desired build is created.

Of these two workflows, the timestamp manipulation logic is useful only for the incremental build workflow.

That's interesting. What use-case do you have where you'd want to build Chromium once first, apply domain substitution, then re-run the build?

The Bromite build process is a bit like that:

build the vanilla Chromium (only some small patches applied, and the GN args of course): https://www.bromite.org/chromium
then build Bromite with all the other patches, including the domain substitution

The Chromium builds are important because before a bug is submitted for Bromite it needs to be tested against vanilla Chromium first (yes, we often incur in upstream bugs which become visible downstream because of specific feature/GN flags combinations).
In general you want to make the best out of ninja, C++, Java own invalidation systems, and ccache's one; the changes in the comments paddle against all of them as at least the parser must run to find out that nothing changed.

By the way, even in your step 2 you could take advantage of less changed files.


feat(validation): add withdirtysavebutton hoc

Proposed Changes
The idea of this HOC is to use the generic validation to wrap a button that has all the required behavior according to the components it must validate.
The Button is bound to one or multiple "validationIds". Then, for all the ID states:
If there are errors: Button disabled, shows the error tooltip
If there are warnings: Button enabled, shows the warning tooltip
If there is no dirty component: Button disabled, shows the dirty tooltip.

Potential Breaking Changes
None
Acceptance Criteria

[ ] The proposed changes are covered by unit tests
[ ] The potential breaking changes are clearly identified
[ ] README.md is adjusted to reflect the proposed changes (if relevant)

Codecov Report

Merging #1435 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1435      +/-   ##
==========================================
+ Coverage   98.98%   98.98%   +<.01%
==========================================
  Files         492      493       +1
  Lines       10218    10249      +31
  Branches     2358     2367       +9
==========================================
+ Hits        10114    10145      +31
  Misses        104      104

Impacted Files
Coverage Δ

...mponents/validation/hoc/WithDirtySaveButtonHOC.tsx
100% <100%> (ø)

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 e993ee6...cbc3777. Read the comment docs.

Added an example usage in the Button page!
Usually, there should be other components (such as Inputs) that would expose their "validation state" to the world and the Save Button would use those components' ids.
But for the sake of the example, I felt the three checkboxes allow more testing flexibility.

Feel free to merge this when you want :)


How does it compare to github.com/iovisor/gobpf

Hi,
I am trying to learn about eBPF and interested in writing BPF code in C and then call from my Go library. I am 2 weeks into my exploration into this. So, pardon my ignorance.  How does it compare to https://github.com/iovisor/gobpf ?
Thanks.

Hi Tamal,
From my point of view, gobpf is designed to instrument running systems for
debugging. You can feed it C, and it will transparently compile it to eBPF.
To achieve this, it calls a C++ library called libbcc which parses and
preprocesses your C code and then compiles it using an embedded LLVM. This
makes it very powerful. The downside is that you probably need to package
libbcc including LLVM yourself. I my personal experience it is easy to get
something running with gobpf, but it becomes incredibly hard to debug when
something goes wrong. One of the biggest hurdles is the way data is
serialised when reading / writing maps, which uses a custom string format.
This package is designed to be used in long running services that use eBPF.
You'll have to compile to eBPF yourself, but in return you get a pure Go
package which is easy to debug and contains several orders of magnitude
less code than gobpf.
I personally also think that our API is a bit nicer that gobpf (especially
for maps), but then I am biased :)
Let me know if you have more questions!

Thanks for the detailed answer. It is starting to make sense. I agree that shipping  LLVM with prod application is not preferred. Instead precompile and bundle the generated ELF files. I also found https://github.com/andrewkroh/go-ebpf project which takes a similar view but uses gobpf to load ELF files.
One thing is not clear to me if the cBPF reference https://github.com/iovisor/bcc/blob/master/docs/reference_guide.md#bpf-c is purely reference to kernel ABI or some custom helpers bcc project has written. The latter seems to be the case. Am I right?

Yes, the map macros are a BCC specific thing. The actual ABI is documented in the kernel. It's not too different from BCC though. You'll need some header files to get started, I recommend you have a look at the ones from the cilium project.

@tamalsaha I'm going to close this. Feel free to keep asking questions, of course.


[bn_layer] Remove unused gradients

Remove ununsed gradients for mu and variance for the batch normalization layers to remove unnecessary memory usage.
Self evaluation:

Build test: [x]Passed [ ]Failed [ ]Skipped
Run test: [x]Passed [ ]Failed [ ]Skipped

Signed-off-by: Parichay Kapoor<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.4.20191203. Thank you for submitting PR #444. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://nnsuite.mooo.com/.


Enhancement: Enable and configure php_unit_test_annotation fixer

❗ Blocked by #903.
❗ Blocked by https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/3312.
This PR

[x] enables and configures the php_unit_test_annotation fixer
[x] runs make cs

Replaces #884.
💁♂ For reference, see https://github.com/FriendsOfPHP/PHP-CS-Fixer/tree/2.9#usage:

php_unit_test_annotation
Adds or removes @test annotations from tests, following configuration.
Risky rule: this fixer may change the name of your tests, and could cause incompatibility with abstract classes or interfaces.
Configuration options:

case ('camel', 'snake'): whether to camel or snake case when adding the test prefix; defaults to 'camel'
style ('annotation', 'prefix'): whether to use the @test annotation or not; defaults to 'prefix'

This post is to challenge annotation style, not PR itself.
With annotation style, how would one handle former testGetName() {} test ?
With annotation style, it would be
/** @test */
public function getName() {}

which would crash on compilation level, as getName is in parent class already, yet it is not a test and has different prototype

I wouldn't write a test for a getter unless there was some behavior behind that interface. Would you mind opening an issue to discuss? Further comments I would have are long-winded and would distract from this PR.

getName is an example, you have a lot more methods in that base class you know? :)
For me it's exactly this PR concern, as this PR is aiming to enforce some rule, which (in my opinion) is problematic, as it could lead to conflicts with base class.
That's why I'm raising concern here, to avoid "happy merging" of style change, and then, in other issue, realize that given style could be problematic.

getName is an example, you have a lot more methods in that base class you know? :)

Sure! Haha.
First, I expect this fixer (and this PR) to break a few things (for this project, in this particular case). Our preference isn't just use of annotation, but also a specific naming convention for test methods. In the case of getName (if I stick with this), we would actually have:
/** @test */
public function get_name() {}

# Or...

/** @test */
public function it_gets_the_name_of_something() {}

Which should not conflict with any system under test or TestCase-inherited method name.

OK, combining multiple "exotic" (for me) rules will indeed end up with safe setup :+1:
I must admit every time I see this snippet behat come to my mind, not phpunit ;)

@keradus @mdwheele
For the record, as I pointed out in https://github.com/opencfp/opencfp/issues/882#issuecomment-349809362, I don't think that using the @test annotation adds any value (at all), but I'm fine using it when the projects dictates it, and there's a way of enforcing it.

same here, so I would prefer to use name prefix instead,
but still using only one syntax and have it automatically checked provides a great value :+1:

Thank you, @BackEndTea!


ruff format out of place?

The default behavior of ruff format is to do an in-place rewrite of the provided files. If you pass source code in via stdin, ruff will output the formatted source to stdout.
It would be great to have an option where we can pass multiple files into ruff format, and get a structured response back with formatted sources for each of the files, somewhat analogous to ruff --output-format=json <files>.
This would be helpful for a project like ours (PyTorch) which calls out to ruff programmatically from various tools.
Happy to contribute this if folks are okay with it.

Thanks for the issue and offer to contribute :)
We're thinking about rewriting our LSP in Rust so it can be in ruff directly. I wonder if that would help with your use case? I think it'd provide an API like what you're looking for.
I'm not sure if different output formats make sense in the ruff format CLI. Curious what @MichaReiser thinks.

It's funny. I've just been talking with @charliermarsh about this because it would be nice if range formatting could return only the portion of the code that needs replacing together with the range that must be replaced rather than the entire file.
We concluded that it would be nice to have but will no longer be necessary once we've rewritten our LSP in Rust because it can then call the internal API directly. I also think that promoting the LSP as a programmatic Ruff API (until we have a Python API) has benefits:

It keeps the CLI API smaller and removes the need to maintain two programmatic APIs
The LSP is well-tested because it is used in IDEs
The LSP is a server, Ruff can cache state between calls, potentially making it faster than spawning the CLI for each file
There's an official specification (we don't need to come up with good APIs)

The main downside is that using it is more involved. For example, to format a file:

Start the LSP process
Send the initialize request
Send the open file request
Send the format request
Send the close file request (optional, but you may want Ruff to release some memory every now and then)
Send the shutdown request
Wait for the process to end

I'll close this in favor of https://github.com/astral-sh/ruff/issues/659, which asks for a Ruff API (not just formatting).


Frequently skips songs halfway through and fails to load songs (http links)

Constantly getting errors like this: https://hastebin.com/raw/iwanerakur
There is absolutely nothing wrong with the audio file. It plays fine in my browser, so I can only conclude that there is something wrong with this library.

We can't see your error, use http://pastebin.com instead of hastebin

Report details inaccessible.


Mark Melodic as End-of-Life.

Note to rosdistro reviewers to please not merge this right away; I'll do it once we are ready.
@nuclearsandwich Copying and modifying your list from https://github.com/ros/rosdistro/pull/37746#issuecomment-1608100563:
Melodic build farm wind-down

[ ] Stop merging all melodic-related ros/rosdistro PRs
[ ] Disable melodic jobs from ros-infrastructure/ros_buildfarm_config: https://github.com/ros-infrastructure/ros_buildfarm_config/pull/223
[ ] Disable jobs using the method described in https://github.com/ros-infrastructure/ros_buildfarm/blob/master/doc/ongoing_operations.rst (but with batching)
[ ] Merge this PR
[ ] Update distro in https://github.com/ros-infrastructure/rosindex/blob/ros2/_config.yml
[ ] After a few weeks, assuming that no one has asked to resurrect melodic for a fixup sync, the jobs can be deleted using a modified copy of the disabling script.

+ create a final snapshot made available on snapshots.ros.org :pray:  (cross-referencing https://github.com/osrf/docker_images/issues/660#issuecomment-1610650065))


Add FMC controller via stm32-fmc crate

The stm32-fmc crate is still a work in progress.
Todo:

[ ] Add example

Thanks for the comments @ryan-summers! I think these comments are relevant to the design of the stm32-fmc library as well as this PR (which was somewhat expected, since this is the first implementation).

@richardeoin I'm definitely seeing how some of these comments are more applicable to stm32-fmc after some further review - take a look at some of my feedback on the PREC structure implementations - it may be worth investigating changing the API to use borrowed refs to the PREC instead of taking ownership? That would solve use cases like this one where a struct keeps hold of the PREC.

I've committed one solution that works with the current PREC API, but it'll be worth looking at it again when #117 is resolved

bors r+


Fix memory leaks in custom executor

When one calls elog(ERROR,... it longjmp out of the current stack leaving no chance for the C++ to be executed.
This PR is a first iteration toward what we want to rationalize (cf. https://github.com/duckdb/pg_duckdb/issues/93 ):

keep a function with a pure C++ "flavor" (object creation, exceptions, etc.)
call it in a new wrapper that copies out the error message and uses PG mechanism to throw the error

This fixes https://github.com/duckdb/pg_duckdb/issues/120, even though there still seem to be a small leak with DuckDB's PrepareQuery leftover (to be followed-up separately)

Thanks, if I'm reading this correctly, we add DuckDBFunctionGuard to catch a c++ exception so we can perform cleanup on the postgres side before propagating this error upward?

Yep, that's correct!


Step 2 test e2e clarification

If our controller is available on the global namespace then we could simply instantiate it with a mock scope object:

test/e2e/scenarios.js:

Following the guide on step 2, the sample code could be improved. I followed the steps and added the sample code to test/e2e/scenarios.js. I tried it out and I was not able to get it to work.
The statement "if our controller is available on the global namespace" might need clarification...either there should be a protractor example here that works or there should be steps to show the user how to add the controller to the global namespace.

Yes I agree, this is not very clear what needs to be done here.
Here is the result/error I see with the mock implementation in e2e tests (scenario.js):
Failures:
  1) PhoneListCtrl should create "phones" model with 3 phones
   Message:
     ReferenceError: PhoneListCtrl is not defined

then with the $controller (Testing non-Global Controllers) also added in e2e tests (scenario.js):
Failures:
  1) PhoneListCtrl encountered a declaration exception
   Message:
     TypeError: module is not a function

It is not clear why we jump from e2e tests to unit tests.
Note that with unit tests in "controllersSpec.js", it is working well (at least with the "$controller code")

These concepts have been clarified a bit here and there.
It has an example of testing a controller IFF it were on the global namespace (which it isn't). Then it shows how we can retrieve and test the controller (using the $controller service), while still using good practices and not polluting the global scope.
If you think this is still confusing, please open an issue on https://github.com/angular/angular.js (since this is about the wording/text, not about the code of the tutorial itself.


Lightning GPU v0.25.0 release candidate

Before submitting
Please complete the following checklist when submitting a PR:

[x] All new features must include a unit test.
If you've fixed a bug or added code that should be tested, add a test to the
tests directory!

[x] All new functions and code must be clearly commented and documented.
If you do make documentation changes, make sure that the docs build and
render correctly by running make docs.

[x] Ensure that the test suite passes, by running make test.

[x] Add a new entry to the .github/CHANGELOG.md file, summarizing the
change, and including a link back to the PR.

[x] Ensure that code is properly formatted by running make format.

When all the above are checked, delete everything above the dashed
line and fill in the pull request template.

Context: This branch holds the upcoming changes for the v0.25.0 release of PennyLane Lightning GPU.
Description of the Change: Includes bugfixes, and documentation updates for the upcoming release.
Benefits:
Possible Drawbacks:
Related GitHub Issues:

Looks good!


[Feature] Search Other Databases

Feature: The ability to import from other DApps
Why: There are many decentralized video platforms including KopyKate , DTube, PeerTube, and more. Personally, I believe the one to win will be the one that includes all protocols in one client.
How? I have seen some other networks allow users to point to a URL or Localhost and load data from there too. Obviously this will be for technical users who want to have this support.

Similar to my response in https://github.com/lbryio/lbry-desktop/issues/1956, we will not be supporting other databases via the desktop app. Down the road the LBRY protocol will support other source content outside of LBRY's P2P system.


Recommended Filter Setting Mucks with Build

If I set this:
excludeFilter.in(unmanagedSources.in(headerCreate)) := "*.scala"

Then compile no longer compiles those files.
There should be a way to exclude stuff without messing with the other tasks.

Agreed. Also, the docs are wrong, nested scoping has no effect.


spawners: cache LFS objects on separate volume

Set Git config lfs.storage to a separate volume that can be shared among notebook servers spawned for the same project.

While this can be a good idea, how will we be providing the shared volumes?

Don't think this is going to happen. Instead we are investigating ways of streaming data directly from LFS.


link to contribution is broken

Title of change
why the change and what has changed
Checklist

[ ] Unit tests written
[ ] Manually tested
[ ] Prettier & ESLint were run
[ ] New dependencies are included in package-lock.json

Screenshot
insert screenshot if needed

Deployed to: http://staging.quran.com:32787


Start/Stop times in query params

Query params should support start/stop times to timebound requests.

Currently, the FireFly explorer has very limited time filtering capabilities. It only allows the user to select the relative time range of the last hour, 24 hours, 7 days, or 30 days. Replacing that with a full date/time range picker component is desired.
Currently material ui has date/time picker components, but they don't quite meet the requirements straight out of the box. Something like grafana provides (see picture below), with relative time ranges and the ability to provide custom absolute ranges is the end goal.


Content areas should be deleted when removed from a template

Renaming a content area should cause a new one to be created and the old one to be deleted
Deleting a content area should cause it to be deleted
Saving a template with an existing content area should not cause deletion and re-creation

I think points 1 and 3 are done in this line: https://github.com/sunlightlabs/datajam/blob/master/app/models/event.rb#L140

I think that this two items are opposed:

Renaming a content area should cause a new one to be created and the old one to be deleted
Saving a template with an existing content area should not cause deletion and re-creation

In https://github.com/sunlightlabs/datajam/blob/master/app/models/event.rb#L137-142 new content areas are generated or the existing ones get updated.
I've pushed a commit to clean up unused content_areas (https://github.com/sunlightlabs/datajam/blob/master/app/models/event.rb#L135-136) this fulfills the issue or am i missing something.

This looks close to working. The problem I see here is the orm call that initially generates existing. It seems to me that it should not care about the area_type, and should only update_attributes in the existing.any/else block if new area_type differs from existing area_type. Make sense?
As an aside, it may become desirable to add a status flag to content areas so they can be included or excluded when rendering a page, without affecting related datasets. For example, If a user has a chat_area with a log of messages, perhaps it would be good to not destroy or disassociate them if the chat is renamed or removed. I think this is more a symptom of an interface implementation problem than a technical one, so perhaps let's wait and see how it plays out.


changed before and afterAll to before and afterEach

unskipped all the entry tests
changed beforeAll and afterAll to beforeEach and AfterEach respectively
refactored the SetEntriesTest file accordingly

closing this PR since this issue was already fixed in another PR -> https://github.com/Laserfiche/lf-repository-api-client-java/pull/110


Compare example PDFs with reference copies

This change is based on @jelmersnoeck's initial PDF comparison code. In order to compare two PDFs, their internal resource catalogs must be similarly sorted and their internal creation timestamps must be the same. Methods were added to enable this. The catalog order needed to be addressed because gofpdf uses hash maps for internal resources and, when writing them to the PDF document, the non-deterministic iteration order resulted in inconsistent internal structure.
A helper function to compare PDFs was added. This is called by the example.Summary method if a reference file corresponding to an example PDF is found in the pdf/reference directory.
This change has not been tested on Mac or Windows yet, nor with versions of Go earlier than 1.5. Verification that it works in these different environments will be appreciated.
A desirable side effect of having the reference PDFs committed to the repository is that we can include links to them in the documentation.

I had a quick look over this (I'll have a more in-depth look later on). Just wondering if it's worth it extracting the functionality to get the keys from a map in a separate function?

Just wondering if it's worth it extracting the functionality to get the keys from a map in a separate function?

Very possibly. The problem with using a function to return a slice of keys is that one function would have to be written for each value type. For example, one function for map[string]foo and another for map[string]bar. It's too bad that Go doesn't have a builtin that returns the keys of a hash in a slice. Easy to generalize with reflection, but that would be suboptimal.

Test fails on Windows, apparently in the first line:
< 0000000  25 50 44 46 2d 31 2e 33  0a 33 20 30 20 6f 62 6a  |%PDF-1.3.3 0 obj|
> 0000000  25 50 44 46 2d 31 2e 33  0d 0a 33 20 30 20 6f 62  |%PDF-1.3..3 0 ob|
< 0000010  0a 3c 3c 2f 54 79 70 65  20 2f 50 61 67 65 0a 2f  |.<</Type /Page./|
> 0000010  6a 0d 0a 3c 3c 2f 54 79  70 65 20 2f 50 61 67 65  |j..<</Type /Page|
< 0000020  50 61 72 65 6e 74 20 31  20 30 20 52 0a 2f 52 65  |Parent 1 0 R./Re|
> 0000020  0d 0a 2f 50 61 72 65 6e  74 20 31 20 30 20 52 0d  |../Parent 1 0 R.|

The differences are all newlines. I'm not sure why they'd be different, but I expect that to be a pain to enforce across the codebase. Perhaps another regex would be a good idea?
...
Did I really just say that?  :)

@marcusatbang, thanks for checking on Windows.

The differences are all newlines.

How naive I was to think the PDFs would have normalized line endings.

Perhaps another regex would be a good idea? ... Did I really just say that? :)

Ha! Regrettably, they may be the most expedient solution here. It's simple to put in place and maybe we can think of a better solution later.

How naive I was to think the PDFs would have normalized line endings.

Yeah...
Looking at a PDF generated by Illustrator CS6, it for some reason uses 0d (\r, really old Mac standard) for newlines. The diff I pasted above shows the first using 0a (\n, C and Unix standard) and the second using 0d0a (\r\n, current Windows standard).
A quick googling doesn't suggest that either standard is more "correct" for PDF, so I suggest you pick one (probably \n) and enforce that throughout.
Remember that if you change the length of the newline code in an existing PDF, offsets will no longer point to the start of the correct element so it'll be corrupted. This probably means that a regex won't work, because it won't just be the newlines that change, it'll be the offsets as well.

Wait... is git changing the line endings when it checks out?
The test now passes. I'm not sure I understand why.

Remember that if you change the length of the newline code in an existing PDF, offsets will no longer point to the start of the correct element so it'll be corrupted. This probably means that a regex won't work, because it won't just be the newlines that change, it'll be the offsets as well.

Ouch. Good observation.

The ideal solution would be code that understands the structure of a PDF and can determine whether they're equivalent regardless of being in a different order and using different IDs internally. But that would probably be a great deal of work.

Your earlier comment is looking more and more like the right way to approach this.

Wait... is git changing the line endings when it checks out?

The test now passes. I'm not sure I understand why.

Did you copy pdf/*.pdf to pdf/reference? If the reference files were created on Windows, all examples files should match.

I just tested this on mac (ref 212c47a), no PDF failures, but I've got an internal package failure.
Output: https://gist.github.com/jelmersnoeck/d9a90632ff27c3ac1fe2
@marcusatbang I've got the same behaviour here. On 0e7f142 it fails for PDFs as well here.

Ah, right. I didn't touch a thing, just made sure I had a clean checkout.

The ideal solution would be code that understands the structure of a PDF and can determine whether they're equivalent regardless of being in a different order and using different IDs internally. But that would probably be a great deal of work.

Your earlier comment is looking more and more like the right way to approach this.

That could conceivably be hooked off the FPDI port I've got going here... if you don't mind the fact that I'm not even within fifteen ballparks of finishing it.

That could conceivably be hooked off the FPDI port I've got going here... if you don't mind the fact that I'm not even within fifteen ballparks of finishing it.

I'm fine with waiting.

@jelmersnoeck I've got the same behaviour here. On 0e7f142 it fails for PDFs as well here.
Problems with those two files are expected since I merged your aligned write fix. (They are the files that had missing space problems.) I commited replacements that should work properly now.

Oh ok, that makes sense.
Regarding multiple systems, would it be helpful to have something like Travis-CI set up? It currently supports Linux and OSX builds: http://docs.travis-ci.com/user/multi-os/

Depending on which of the four or five git for Windows tools you're using and what settings you picked on installation, there's a good chance git will rewrite text files for line ending. For normal files this is fine, but for a reference file you want to prevent it.
To prevent this confusion, a good first step would be to add a .gitattributes containing:
*.pdf    -text

Regarding multiple systems, would it be helpful to have something like Travis-CI set up?

It could be. The tests would be a lot more valuable if the generated PDFs could be compared byte-for-byte, but it's looking like that goal may be really hard to achieve.

To prevent this confusion, a good first step would be to add a .gitattributes containing: *.pdf    -text

Done. Good advice.

Enforcing standard newlines regardless of the platform is still a good idea, even if it isn't sufficient to make them directly comparable.

Tests are all passing on Windows, and both the generated and reference files are consistently using \n even on Windows. I think there was more confusion than bug here. Panic over.

Tests are all passing on Windows, and both the generated and reference files are consistently using \n even on Windows.

I too just successfully tested the branch on Windows (XP, using go version 1.3) and OS X (10.7, using go version 1.5.1).
Was it making sure *.pdfs get checked out as binaries that resolved this problem?

I'm not certain, but I think so. It certainly contributed to my confusion, and that's what you don't want in tests.

My tests are on Window 10 and Go 1.4.1

Good -- it looks like we are getting good platform coverage for this branch.

I can probably find a few minutes at work tomorrow to run the test on Ubuntu and CentOS

Now that we will have these reference PDFs in the repository, it would be nice to have links to them in the README. However, when I click access a file residing on Github (for example, basic.pdf) my browser (Chrome) downloads it rather than renders it. Any insights?

It's not the native browser support, but you could link to the GitHub viewer.

Test fails on Ubuntu.
$ go test
--- FAIL: ExampleFpdf_CreateTemplate (51.363065ms)
got:
< 0000060  3c 2f 4c 65 6e 67 74 68  20 34 30 33 3e 3e 0a 73  |</Length 403>>.s|
> 0000060  3c 2f 4c 65 6e 67 74 68  20 32 39 38 3e 3e 0a 73  |</Length 298>>.s|
< 00000b0  30 30 20 67 0a 71 20 25  21 46 28 66 6c 6f 61 74  |00 g.q %!F(float|
> 00000b0  30 30 20 67 0a 71 20 31  2e 30 30 30 30 20 30 20  |00 g.q 1.0000 0 |
< 00000c0  36 34 3d 31 29 20 30 20  30 20 25 21 46 28 66 6c  |64=1) 0 0 %!F(fl|
> 00000c0  30 20 31 2e 30 30 30 30  20 30 2e 30 30 30 30 20  |0 1.0000 0.0000 |

That's quite a big difference in the length. The longer version is my locally generated copy. Here's that object in the reference:
4 0 obj
<</Length 298>>
stream
0 J
0 j
7.09 w
BT /F0 16.00 Tf ET
0.784 0.392 0.000 RG
0.000 g
q 1.0000 0 0 1.0000 0.0000 0.0000 cm
/TPL1 Do Q
q 1.0000 0 0 1.0000 0.0000 -85.0394 cm
/TPL1 Do Q
q 1.4000 0 0 1.4000 0.0000 -506.8347 cm
/TPL1 Do Q
113.39 246.61 m 170.08 246.61 l S
BT 113.39 274.96 Td (Template example page 1) Tj ET

endstream
endobj

and here it is in my generated copy:
4 0 obj
<</Length 403>>
stream
0 J
0 j
7.09 w
BT /F0 16.00 Tf ET
0.784 0.392 0.000 RG
0.000 g
q %!F(float64=1) 0 0 %!F(float64=1) %!F(float64=0) %!F(float64=0) cm
/TPL1 Do Q
q %!F(float64=1) 0 0 %!F(float64=1) %!F(float64=0) %!F(float64=-85.04) cm
/TPL1 Do Q
q %!F(float64=1.4) 0 0 %!F(float64=1.4) %!F(float64=0) %!F(float64=-506.8) cm
/TPL1 Do Q
113.39 246.61 m 170.08 246.61 l S
BT 113.39 274.96 Td (Template example page 1) Tj ET

endstream
endobj

Something wrong with the floats in the printf here https://github.com/jung-kurt/gofpdf/blob/compare-reference-pdf/template.go#L82?

@marcusatbang, good catch. That business with the floats is the last problem I would have expected. Does it occur with each test run?

@jelmersnoeck

It's not the native browser support, but you could link to the GitHub viewer.

That should work. I think some features may not be supported, but it is convenient for someone who wants to quickly view sample PDFs.

@marcusatbang, good catch. That business with the floats is the last problem I would have expected. Does it occur with each test run?
It appears to be consistent, yes.

It is only within the Fpdf_CreateTemplate.pdf file.

What is very curious to me is that the floats that the fmt package reject (for example, %!F(float64=1.4)) have the same values of the reference file (1.0000, 1.0000,  0.0000,  0.0000; 1.0000, 1.0000,  0.0000,  -85.0394; etc).
What version of go is being used?

Ah, that's Go 1.2.1, which is the version installed by Aptitude. That may be the problem.

Maybe, but it's nevertheless a concern.

Removing the precision from that format (replacing %.4F with %F) results in a valid file that contains 1.000000 instead of 1.0000. It doesn't match the reference file, but it works.

Everything about this is interesting. We could remove the format precisions on that one line and recommit a new reference file, but I'm not sure I understand the implications yet.

template.go is the only source file that uses 'F' instead of 'f'. In the current documentation, 'F' is a synonym for 'f'. Can you try replacing %.4F with %.4f?

That worked. Replacing %.4F with %.4f on lines 82, 129 and 131 makes the test pass.

Prior to March 2014, %F was not permitted in format statements. Here is the change log.

That worked. Replacing %.4F with %.4f on lines 82, 129 and 131 makes the test pass.

Good! I'll make the change on my branch.

Test passes on a fresh checkout. Approved.

(and to clarify my previous comment,

Removing the precision from that format (replacing %.4F with %F) results in a valid file that contains 1.000000 instead of 1.0000

I'd actually replaced them with %f and didn't realise the difference was significant)

Test passes on a fresh checkout. Approved.

Thanks for work on this.

I'd actually replaced them with %f and didn't realise the difference was significant)

That float specifier was an interesting wrinkle. One seldom considers that adding support for a feature (in this case, '%F') will have repercussions going forward.

Is there anything else you need to approve this for merging? It's pretty big, so I can understand being hesitant.

Is there anything else you need to approve this for merging?

I was away from my desk for a few days, so I wanted to wait until I returned in the event some other gotchas materialized. Even though the merge is large, at least the comparison of example PDFs with reference documents is easily disabled if we need to back out.
I'm currently wondering how to handle links to the reference PDFs. Currently they are displayed using GitHub's basic viewer, but that does not support a number of features that the PDFs showcase such as transformations and bookmarks. The links can be to the raw versions of the reference files, in which case the PDFs get downloaded. This is more cumbersome for the user, but at least a full-featured reader can be used to examine the documents. Any thoughts?

The files themselves are in the repo, so the links in the README are just for easy browsing, right?

Correct. Links would allow someone who hasn't checked out the repository to take a look at the example documents.

Test still pass on Ubuntu with Go 1.2.1. I'll check Windows tonight.

@jelmersnoeck wrote:

Regarding multiple systems, would it be helpful to have something like Travis-CI set up? It currently supports Linux and OSX builds: http://docs.travis-ci.com/user/multi-os/

Good idea -- I just registered the project with Travis CI and configured it to test on both Linux and OSX. Too bad Windows is not supported too.


Change successful "unlock" reply

Currently, the reply for successful "/v1/steady-state" requests is misleading:

unlocked reboot lease for <OWNER_ID>

This response is sent even

when the machine ID is NOT the holder of the lease (which means that the lease is NOT unlocked),
or when there's no reboot lease (in which case the reply is unlocked reboot lease for )

This commit changes the reply to use a generic message "steady-state confirmed" (which is what Airlock logs in that case).
It is also possible to use three different messages, e.g:

if the reboot lease was actually unlocked (request.ID = ownerID):

unlocked reboot lease for <OWNER_ID>

if the reboot lease is held by another node:

steady-state confirmed for <REQUEST_ID>, reboot lease held by <OWNER_ID>

if there's no locked lease:

steady-state confirmed for <REQUEST_ID>

I think its ok as-is, like a kv store that says "deleted" on successful delete, regardless of whether anything was actually deleted. The client shouldn't care about the prior state. Thanks though!


Empty Package.swift no longer supported

August 2016 version of Swift 3 no longer supports empty Package.swift

043ac7bbfd87ae0c8c632a267b6256c9ddf10460