Is there any way to make this dependency any lighter?

I am talking about disk usage. Yes, 2.7 MB is getting... troublesome in one scenario I have. Can you give me any hints on an easy way to cut this down (the more the better)?
I only need FSTObjectInput and FSTObjectOutput as drop-in replacements for Java's ObjectInputStream and ObjectOutputStream. Should run under OpenJDK 6 (or newer) and Oracle JDK 6 (or newer). I see that some dependencies are there because of JSON, Android, etc. Maybe I can make my own build without them?
I tried to pretty print this so that it can be used as a reference question in the future.
Your help is much appreciated.

yes. for pure serialization to work (no android, no json, no structs) there is logically zero dependency. However you need jdk 1.7.
However there probably will be runtime errors due to static init code and stuff. Needs to be converted into Class.forName'y style code then ..

Yeah, supposedly. I went check it before I replied. I've been using 2.33 successfully with OpenJDK6 for a while now. I am not making this library with Java 6, I just USE it with Java 6.
java -version
    java version "1.6.0_36"
    OpenJDK Runtime Environment (IcedTea6 1.13.8) (6b36-1.13.8-0ubuntu1~14.04)
    OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)

in pom.xml
    <dependency>
        <groupId>de.ruedigermoeller</groupId>
        <artifactId>fst</artifactId>
        <version>2.33</version>
    </dependency>

But that's what I thought, I would need to make some corrections myself to get it to build before using it without its dependencies. You wouldn't know of a similar open source library out there, would you?

there is kryo, however its not compatible and sometimes requires some extra work to make classes serializable.
I don't know of a similar project to fst (that's why I created it :) ).
You can do a branch of 2.4x and get it to run on 1.6 (1.7 would be better), I might merge the diff.
Even better would be a pull request achieving what you want without breaking json, structs + offheap.

Oh, you are missing the point. I already have a solid, magic piece of software running with amazing results under Java 6. Thanks you for starting it (+1). I just need the dependency to be lighter. I need exactly to break JSON, structs, etc. For my project. I might make it open source in the end.

Hm .. I am confused now. Serialization does not need the dependencies, so all to be done is to modify the code it does not throw an (unnecessary) "ClassNOtFound" during init. This way one could simply drop the dependencies as long only fst serialization is used. If you have already done that, is there a github repo with that ?

Will look into doing it. No need to be confused, that's exactly what I was looking for.

 God.

always on :)

Any news on the issue? I'm going to strip the deps on my fork for my internal needs like this (jackson removed) https://github.com/korniltsev/fast-serialization/commit/dda3312f9239f439b828e62fbcb8ccfea24c4a3d I have not looked into code preciesely but it looks like I can do the same with javasist ( I am not really sure javassist works well on android ).
@RuedigerMoeller do you have plans on making dependencies optional? I can try to work on PR if you  let me.

I am accepting pull request, however stripping dependencies requires some careful work, I currently have not the need for that feature and no time/motivation to work for other peoples needs ;).

its probably not a good idea to pay a performance price.
if using FST to connect to a backend from within an android client, its very likely to use JSON encoding because of versioning safety

I am an android engineer and the reason I want fst to be smaller(modularized) is 65k dex method limit. In short: good android applications can't have more than 65k methods and fst is huge and brings 9k of them.

There are certainly usecases when you need only some part of the lib, for example default/android serialization and don't need json,kson,minbin,structs. In fact we use fst at ok.ru and when we run release build, proguard removes json/kson,minbin silently because it is not used. The problem is javasist&structs. We don't use it and afaik we can't use it on android. However since the FstStruct.class and some other classes are used in default configurations, proguard can't shrink it.
So I have an Idea of splitting the lib in modules with no performance price paid at all. Here is my plan:

Fix tests. https://github.com/RuedigerMoeller/fast-serialization/pull/162
Create a branch 'modularization' and create all next prs agains it. This way we do not pollute master untill we are sure it works/ready.
PR#1 Create module 'core' and move all the sources & tests to core module.
PR#2 Create separate module 'structs' and move all the structs, offheap, onheap, javasist stuff to this module. I should start with structs first, because it is the hardest part and there are some hardcoded stuff in FSTClazzNameRegistry#classForName which makes this move not straightforward. We can probably reuse LastResortResolver to move this stuff("_Struct", "_ActorProxy") aside.
PR#3 Create separate modules for json,kson,minbin. It is pretty easy and straightforward.
Write migration guide since API will definetly change(slightly)
Merge modularization' into master

This way I wil use fst-core on android and if I need I can add fst-json and others.
One more thing. I would like to know the reason behind desicion to keep both gradle and maven in the repo. It is tedious and error-prone to keep both of them. Especially if we agree to modularize fst. Here is an example to convince you leave only one build tool: there is already jackson dependency mismatch.  In pom it is 2.8.1 and in gradle it is 2.5.3.
So @RuedigerMoeller please let me know what you think about it. Please let me know if I can start work on it.
PS: If anyone interested, I've already forked & removed all but default/android configurations for my internal needs here https://github.com/korniltsev/fast-serialization/tree/ok_2.47 .

Another vote for this - it would be great to just be able to import the Android-related components.
@korniltsev - do you have a ProGuard configuration for FST that you could share?

@simonrob No I don't have one. Json and minbin parts are removed by proguard automatically(if you don't use them) and AFAIK javasist and structs parts can't be removed by proguard since they are used in FstStruct, default configuration classes. We've been using our fork mentioned in the previous message for a while, but now we don't and I do not recommend to use the fork.

I'll split+cleanup fst with version 3.0, however it might take some time until then.

@RuedigerMoeller please don't its probably not a good idea to pay a performance price.

There won't be any performance price.

javassist is required only for fst.structs which is a very specialized hack and could be separated in a library.
minbin can be removed completely, its used rarely, in addition JSon can be used instead of minbin
jackson+json serialization can be separated into a separate extension jar.
objenesis is required, but this one is smallish


Allow specifying the language code

By default, don't add anything, but give the user the ability to specify the language code.

Is there any prior art here?
Do any of the importers import any language information, either per post or per site?
Is there any existing convention for specifying this information?

Only the specs as far as I can tell. language is a per site element.

But, because it XML, any element can have an xml:lang attribute.

That is true, but the specs don't mention anything about each element. So it should be a per channel sub-element.

Is there any prior art here at all? Are there any i18n Jekyll plugins/workflows that set language information anywhere?

Are there any i18n Jekyll plugins/workflows that set language information anywhere?

@pathawks There are a number of i18n plugins for Jekyll out in the wild. Octopress's Multilingual is the only one whose development I have followed. https://github.com/octopress/multilingual

I don't see any language element in the Atom spec, but <feed> could have an xml:lang set to {{ site.lang }}, if present. Each <entry> could also have an xml:lang set to {{ post.lang }}. All links could also include hreflang if we can reasonably figure out the language of the resource the link points to.
Would this be reasonable/sufficient? Are there any great examples of feeds from multilingual sites that properly include language information to look to as an example?

This has been fixed by #75

Thanks! Any chance for a new release?


Update MarkTaskCommand when task already marked

If attempting to mark an task that is already done,
a new message is given to the user.
Have changed the function from setIsDone() to markDone(),
since we do not allow undo of completion. The function will return
a boolean hasChanged informing the caller whether or not there
was a change made to the task status.
Testcases were updated

Codecov Report

Merging #231 (6cfe69d) into master (b1295db) will increase coverage by 0.13%.
The diff coverage is 61.53%.

@@             Coverage Diff              @@
##             master     #231      +/-   ##
============================================
+ Coverage     58.94%   59.08%   +0.13%
- Complexity      679      681       +2
============================================
  Files           134      134
  Lines          2609     2610       +1
  Branches        300      301       +1
============================================
+ Hits           1538     1542       +4
+ Misses          981      978       -3
  Partials         90       90

Impacted Files
Coverage Δ

src/main/java/seedu/address/model/Model.java
100.00% <ø> (ø)

...rc/main/java/seedu/address/model/ModelManager.java
61.47% <0.00%> (+0.49%)
:arrow_up:

src/main/java/seedu/address/model/TaskBook.java
62.50% <0.00%> (+2.50%)
:arrow_up:

...c/main/java/seedu/address/model/task/TaskList.java
43.58% <0.00%> (ø)

...in/java/seedu/address/storage/JsonAdaptedTask.java
0.00% <0.00%> (ø)

.../seedu/address/logic/commands/MarkTaskCommand.java
85.71% <100.00%> (+2.38%)
:arrow_up:

src/main/java/seedu/address/model/task/Task.java
85.71% <100.00%> (+0.86%)
:arrow_up:

... and 1 more

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 b1295db...6cfe69d. Read the comment docs.


Register the modal without link

I didn't find in the documentation to register the modal without a link. Is this possible? e.g: I want to trigger the modal when a div is clicked. I can't just use a tag, because the div contain some a tags.

hi @bersujamu Thanks for your patience and apologies for the delay and in reposnding. This is something we've been putting some more thought into recently as a way of further extending Modaal's functionality.
The challenge we're facing currently is how we handle focus states, specifically where do we shift the focus state back to on close for an item that isn't a modaal.
This is the scenario we're planning out: You're currently focused on element A at the top of the page, you scroll down the page so element A is now out of the viewport and interact with element B in a way that won't move your focus to element B, but will open a Modaal dialog. When you close that Modaal dialog, we need to reset the focus, which in this case is element A so the page scrolls back up to focus on element A. Not ideal for the user because you moved past that point and we would ideally allow you to continue where you opened the Modaal from, not somewhere else on the page.
As we get further in working out how to best handle this we'll address this task in conjunction with others and update as required.
Thanks again, and keep watching this space for more updates.

It's been a long time coming, but I've just implemented support for non <a href="#"> triggers such as button, with a new content_source options. See the readme for more detailed documentation, but this can now be used like:
<button class="inline">Show</button>

$('.inline').modaal({
    content_source: '#inline'
});

or for inline attribute application
<button data-modaal-content-source="#inline" class="modaal">Show</button>


Impossible to access menu items properties

Is there a simple way to access the items of a menu using ids?
Currently it seems impossible. Only some really unnecessary complicated solutions such as
https://stackoverflow.com/questions/51861245/python-kivy-kivymd-how-to-fetch-values-of-mddropdownmenu
Any update concerning that issue?

        menu_items = [
            {
                "text": f"Item {i}",
                "on_release": lambda x=f"Item {i}": self.menu_callback(x),
            } for i in range(5)
        ]
        self.menu = MDDropdownMenu(
            header_cls=MenuHeader(),
            caller=self.screen.ids.button,
            items=menu_items,
        )

    def menu_callback(self, text_item):
        print(text_item)```

Yes that is a workaround and  I should probably use something like that.
Still, it would be useful to be able to directly call the properties of the menu items.

I can't imagine a situation where this might be necessary.

Yes that is true. I was so fixating on getting that to work that I did not think that we actually don't need it.


Req: editing key in Zotero pane

Log ID: 7NJTUZ4T-euc
It would be good if we could edit the BibTeX key directly in the right pane of Zotero by simply clicking on the field, in the same way we can edit every other field.
At the moment, to change the key we have to do this:

right click
scan the menu to decide on the right submenu
scan the submenu to decide on the right option
click on 'Change BibTeX key...'

This doesn't sound like a lot until you have to do it several times. The alternative would involve intuitively clicking on the field you are looking at already. Frictionless and more consistent.

The item pane is very resistant to adding editable fields. That I can display the key there already took significant effort.

That's a shame. Speaking of that field, I added Zotero-Dark-Theme and the Citation Key is the only field that doesn't change to white-on-grey:

Not a huge problem of course but I was wondering if there anything that BBT or Zotero-Dark-Theme could do.

@glocalglocal: A future update of Zotero should provide a proper Citation Key field. The new Preprint item type has it already. At the moment, pinning BBT's citation key will write it to the item's Extra field, where it can be edited. In general, you'd want to set up your citation key format such that only a small fraction needs to be changed manually.
Here are some related options that might help:

With the autoPinDelay option, you can have the citation keys pinned automatically.

You could use the "Apps/Menu" key or Shift+F10 as an alternative to right-clicking items. When the item's context menu is being shown, press "B" on your keyboard and then "Enter" to select BBT's "Change BibTeX key..." function.

The Zutilo add-on provides some keyboard shortcuts for BBT. You could set a shortcut for "Pin BibTeX key".  We could also add a new Zutilo shortcut for "Change BibTeX key...".

Hopefully, Zotero's key field will resolve this although IME it can take ages between releases. I try not to overcustomise because it almost always leads to higher maintenance later (eg when something breaks). I only change keys manually to replace long organisation names with something less cumbersome. Thanks for the tips.

Wrt key editing I also want to wait to see what behavior Zotero itself wants to implement. The most plausible behavior seems to me to be what auto-pin does now, combined with with an option for manual refresh. I don't expect the citekey to come soon for all items, but one item already has it, so it's clearly being worked on.

One problem with Extra I see is that it's increasingly becoming a dumping ground for all sorts of things (three add-ons and a referencing style already here).

That is something you'll have to take up with the Zotero team. The extra field is consistently named the appropriate place for plugin data that is meant to sync.
WRT dark mode, I probably need to add a class to the citekey field to have it update, but I don't know what exactly. If you know what it is I'll gladly add it, but I know next to nothing about CSS.

I'm planning to add a Zutilo shortcut for BBT's "Change BibTeX key...". See https://github.com/wshanks/Zutilo/issues/224.

WRT dark mode, I probably need to add a class to the citekey field to have it update, but I don't know what exactly. If you know what it is I'll gladly add it, but I know next to nothing about CSS.

There may be some help coming here.

We'll have to wait for that as I have no burning desire to dive into their CSS.

Looks like @Rosmaninho solved it on their end.


Scanning for tests outside src folder

When I run npm test, jest runs tests on cypress/integration. I've tried to configure through a key in package.json, a jest.config.json and jest.config.js, passing as --config argument. Tried npm test -- --config=jest.config.js too, but it seems to ignore all that.

Hi @Aledosim
This is an old (core) design decision, tests files outside of  src folder are not supported with react-scripts (see https://github.com/facebook/create-react-app/blob/7e4949a20fc828577fb7626a3262832422f3ae3b/CHANGELOG-1.x.md#ensure-application-and-test-files-reside-in-src). That said, you can easily call jest directly with the config file of your choice (eg. jest -c jest.config.js) but you'll need to configure the src targets too by hand (and ensure setupTests.js and so on are called, if you are using the same command to run tests located inside src and so on.

Sorry for my misunderstanding. I really don't want to run tests outside src, but it keep doing it.

Updated to version 2 and it fixed the problem.


Add live metrics api

Addresses #68
Sample output:
{"timestamp":"2021-08-20T13:59:12.831569-07:00","provider":"System.Runtime","name":"cpu-usage","displayName":"CPU Usage","unit":"%","counterType":"Metric","value":0}
{"timestamp":"2021-08-20T13:59:12.831684-07:00","provider":"System.Runtime","name":"working-set","displayName":"Working Set","unit":"MB","counterType":"Metric","value":66}
{"timestamp":"2021-08-20T13:59:12.8321364-07:00","provider":"System.Runtime","name":"gc-heap-size","displayName":"GC Heap Size","unit":"MB","counterType":"Metric","value":4}

TODO:

[ ] Documentation
[x] There is an occasionally issue in the tests where the data comes back partial. This only reproes in test environments.
[ ] Figure out other interesting export formats

Please add entry to /documentation/releaseNotes.md

/azp run


feat: support user config manifest compression

I hereby agree to the terms of the GreptimeDB CLA
What's changed and what's your intention?
Expose ManifestLogStorage compress configuration to user
Manifest log now supports compression but it is not enabled by default. I hope to expose the option to users whether to enable Manifest log compression.
expose a config use_compress to user whether to use Manifest log compression.
[storage.manifest]
checkpoint_on_startup = true
use_compress = true # false by default

Checklist

[x]  I have written the necessary rustdoc comments.
[x]  I have added the necessary unit tests and integration tests.

Refer to a related PR or issue link (optional)
Closes https://github.com/GreptimeTeam/greptimedb/issues/1394
Follow-up of https://github.com/GreptimeTeam/greptimedb/pull/1497

Maybe we need to add a new test suite for compress=true in sqlness tests. To ensure all is fine when enabling compression for region and table manifests.
https://github.com/GreptimeTeam/greptimedb/blob/develop/tests/conf/standalone-test.toml.template
It's not urgent. Can you create an issue to track it?
Thank you.

Consider add file datanode-manifest-compress-test.toml.template and standalone-manifest-compress-test.toml.template under path /tests/conf, then make it run and pass. Is any other needs to be consider? I have checked the code of sqlness runner quickly, only few line change will do.

Consider add file datanode-manifest-compress-test.toml.template and standalone-manifest-compress-test.toml.template under path /tests/conf, then make it run and pass. Is any other needs to be consider? I have checked the code of sqlness runner quickly, only few line change will do.

I think standalone-manifest-compress-test.toml.template is enough to cover. Thanks.

@Taylor-lagrange  Will you add the sqlness test suite or leave it to next PR?

Sqlness code not complicate, maybe we can consider fork and make our own sqlness, The interface provided by the original code is not very flexible

Sqlness code not complicate, maybe we can consider fork and make our own sqlness, The interface provided by the original code is not very flexible

The sqlness maintainer is @waynexia , we can discuss this here or in slack channels.


Building failed. Err: Is gcc.exe installed

Edit: I finally solved this. I installed msys2 and gcc on it, and editted the Path environment variable.
Describe the bug

I was trying https://burn.dev/book/basic-workflow/model.html
The code doesn't compile.
To Reproduce

Expected behavior

Should I compile?
Screenshots

Compiling libsqlite3-sys v0.27.0
The following warnings were emitted during compilation:
warning<EMAIL_ADDRESS>Compiler family detection failed due to error: ToolNotFound: Failed to find tool. Is gcc.exe installed? (see https://github.com/rust-lang/cc-rs#compile-time-requirements for help)
error: failed to run custom build command for libsqlite3-sys v0.27.0
Caused by:
process didn't exit successfully: E:\rust practice\1\burn_test\target\debug\build\libsqlite3-sys-e441b518dd07b560\build-script-build (exit code: 1)
--- stdout
cargo:rerun-if-env-changed=LIBSQLITE3_SYS_USE_PKG_CONFIG
cargo:rerun-if-changed=sqlite3/sqlite3.c
cargo:rerun-if-changed=sqlite3/wasm32-wasi-vfs.c
cargo:rerun-if-env-changed=SQLITE_MAX_VARIABLE_NUMBER
cargo:rerun-if-env-changed=SQLITE_MAX_EXPR_DEPTH
cargo:rerun-if-env-changed=SQLITE_MAX_COLUMN
cargo:rerun-if-env-changed=LIBSQLITE3_FLAGS
TARGET = Some("x86_64-pc-windows-gnu")
OPT_LEVEL = Some("0")
HOST = Some("x86_64-pc-windows-gnu")
cargo:rerun-if-env-changed=CC_x86_64-pc-windows-gnu
CC_x86_64-pc-windows-gnu = None
cargo:rerun-if-env-changed=CC_x86_64_pc_windows_gnu
CC_x86_64_pc_windows_gnu = None
cargo:rerun-if-env-changed=HOST_CC
HOST_CC = None
cargo:rerun-if-env-changed=CC
CC = None
cargo:rerun-if-env-changed=CC_ENABLE_DEBUG_OUTPUT
cargo:warning=Compiler family detection failed due to error: ToolNotFound: Failed to find tool. Is gcc.exe installed? (see https://github.com/rust-lang/cc-rs#compile-time-requirements for help)
cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("true")
CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
cargo:rerun-if-env-changed=CFLAGS_x86_64-pc-windows-gnu
CFLAGS_x86_64-pc-windows-gnu = None
cargo:rerun-if-env-changed=CFLAGS_x86_64_pc_windows_gnu
CFLAGS_x86_64_pc_windows_gnu = None
cargo:rerun-if-env-changed=HOST_CFLAGS
HOST_CFLAGS = None
cargo:rerun-if-env-changed=CFLAGS
CFLAGS = None
--- stderr
error occurred: Failed to find tool. Is gcc.exe installed? (see https://github.com/rust-lang/cc-rs#compile-time-requirements for help)
Desktop (please complete the following information):

OS: win11, vs code latest(probably)
Browser firefox
Version [e.g. 22]

Additional context

@nathanielsimard Thanks.

I solved this problem by installing msys2 and gcc in it, and adding the Path environment variable.


Inputs lose focus on parent re-render

I'm currently experiencing issues (using 0.3.0-rc2) where if you are focused in a generated input and the parent state is changed (forcing an update) then the input will be blurred.
A brief bit of investigation (just watching DOM changes) showed me that the entire form tree is removed and replaced with an identical tree when the parent component is re-rendered.
Is this a known issue within this release?
Reproducing should be quite easy: just a simple form with a textbox and force an update on your parent component to see that you'll lose focus of your input if you were typing.

I think I am witnessing this issue as well

Hi, a quick workaround should be to add:
shouldComponentUpdate: function () {
  return false;
}

to the component containing the form, or to wrap the form with a component with shouldComponentUpdate defined.
Let me know if it works for you.
But I wonder if it would be a good thing to add shouldComponentUpdate to the top level component, here:
https://github.com/gcanti/tcomb-form/blob/master/lib/create.js#L25
That would be an easy fix, what do you think?

Cool, so putting shouldComponentUpdate() => false in will fix the focus issue but then you lose the power of being able to use the form as a "controlled input". Ie. you can no longer pass new value prop in which updates values in the form from outside state.
Also, somewhat related, it seems when you create a form in the render method it will remount the entire new form everytime. Perhaps some internal React evaluation seeing a newly created class everytime? The reason I am attempting this pattern is because I have variable enums so just creating the model & form within render with current state makes most sense following the React pattern. You may have a better way of updating models though which I have probably missed!

well, for my particular use case, i have a Login component that does that already..it just wraps a simple form with 2 fields on a big front login screen. I have a customized way of showing an error message when authentication fails from the server.  If i add shouldComponentUpdate and return false.. that message never gets rendered.
see here
http://www.evernote.com/shard/s349/sh/552b8bb9-e574-436c-a3a5-1e52160622d8/01e55e911aea42d25e1f96314c9791c1
Note:  i am not using the custom error as provided by tcomb-forms
http://gcanti.github.io/tcomb-form/guide/index.html#fieldset-error
because i noticed that when i repeatedly hit the sign in button with an intentionalyl incorrect username and password,, there was  a noticeable "flashing"  of the content as what appeared to be the entire form re-rendering itself.. it was noticeable enough that i went with the custom layout seen above, which was much smoother... ,This also brings me to the reason that i am so interested in autofocus.
I have an onChange handler on my form that removes the custom error div (when present) when the user attempts to enter the email again..this message disappears nicely but the whole form seems to be re-rendering as well and as soon as you type one character the focus is lost and you must re-enter the email and start typing again.. it is kind of quirky...
But, maybe i should just drop all this and go back to using the tcombs-form way of doing form level error messages?  or do you have any other thoughts on this approach.

Looked a little more into the React "Reconciliation" process and tried out some tests to confirm.
When a new React Component is discovered, regardless of whether the rendered output is identical to the existing DOM, if the class is a newly created one it will discard it and replace it with a new identical (only in appearance and structure) tree Ie. component will mount everytime parent is updated.
So the problem is how the render methods for forms use factory methods to create new classes rather than using a set of static classes and placing logic within them and passing data down through props for appropiate nesting situations.
I'm going to try and throw together a quick proof of concept around tcomb-form but it seems there will be a fair bit of refactoring required.
Quick test you can run which should simulate what's going on:
var MyTestComponent = React.createClass({
	componentDidMount: function {
		// Force some updating to simulate state changing and re-rendering
		setInterval(this.forceUpdate.bind(this), 500);
	},
	render: function() {
		var MySubComponent = React.createClass({
			componentDidMount: function() {
				console.log('Mounted sub component!');
			},
			render: function() {
				return (<input type="text" />);
			}
		});

		return (
<MySubComponent />
);
	}
});
React.render(<MyTestComponent />, document.body);

Wow it's complicated. When I wrote tcomb-form the main goal was to build tons of forms for internal backoffices (so static forms). You have to handle pretty dynamic forms. It's an interesting problem, I'll try to help as much as I can.
I wrote this experiment, let me know if something is missing:
var Person = t.struct({
  name: t.Str,
  tags: t.list(t.Str)
});

var Form = t.form.create(Person, {
  fields: {
    name: {
      // auto focus on first rendering
      autoFocus: true
    }
  }
});

var Wrapper = React.createClass({
  shouldComponentUpdate: function () {
    // this prevents to lose focus
    return false;
  },
  onChange: function (value) {
    // this keeps the state in sync with the form
    this.setState(value);
  },
  change: function (state) {
    // this allows to change the form value from the outside
    this.setState(state);
    this.forceUpdate();
  },
  render: function () {
    console.log('wrapper rendered', this.state);
    return <Form ref="form" value={this.state} onChange={this.onChange} />
  }
});

var App = React.createClass({

  componentDidMount: function () {
    // force re-rendering
    setInterval(this.forceUpdate.bind(this), 1000);
  },

  changeValue: function () {
    this.refs.wrapper.change({name: 'changed'});
  },

  render: function() {
    console.log('app rendered');
    return (

        <Wrapper ref="wrapper" />
        <button onClick={this.changeValue}>force change</button>

    );
  }
});

React.render(<App />, document.body);

Cheers for the help! The tcomb libraries are all great and if this issue can be resolved it really will be a perfect solution for easily creating drop in forms for react.
I don't think the above code would solve the issue for two reasons:

When your outside state changes and we call change() an update is forced which will blur the input we had focused. Imagine you had your username field focused as you were typing and then we had to call change() to set some options from an async operation which was happening in the background.
With React your data is usually stateful so usually you just know "something has changed, re-render this block and let the render diff handle what has really changed" rather than creating explicit data bindings which is what React quite importantly helps you avoid.

To get things working in a way which would handle the everyday react/stateful application I'd see there being a single root <Form /> component which would take a model and the usual options object you'd usually pass to t.form.create(opts)
So the public api would look more like:
React.createClass({
  render() {
  	let options = {
  		fields: {username: {}}
  		...
  	};

  	return (
  		<Form model={UserModel} opts={options} />
  	);
  }
});

This root component would hold the state of the entire form (I think like it currently is) so if any part of your models or options change they are still stored and passed down.
Internally you'd have static components for each type which knew how to render itself with passed props. Then we use the normal react method of rendering these rather than having a factory create new classes every re-render which cause the DOM destruction.
At a glance I think this essentially involves moving all the logic of handling passed 'context' and 'options' from factory functions into the react classes (render methods???) themselves.
var Components = {};

function getComponent(model) {
	return Components[utils.getType(model)];
}

function generateContext(model, options) {
	return {}; // Some object which describes to a component how to render itself
};

var Form = React.createClass({
	render() {
		var Component = getComponent(this.props.model);
		var context = generateContext(this.props.model, this.props.opts);

		return (<Component context={context} />);
	}
});

Components.Struct = React.createClass({
	render() {
		var props = this.props.contexts.props;
		var renderFields = [];

		for (var propName in props) {
			var Component = getComponent(props[propName]);
			var context = generateContext(props[propName], this.props.context.opts);

			renderFields.push(<Component context={context} key={propName} />);
		}

		return (

{renderFields}

		);
	}
});

Components.Textbox = React.createClass({
	render() {
		var Template = getTemplate(this.props.context.model, this.props.context.opts);
		var templateProps = {
			placeholder: ...
		};

		return (<Template {...templateProps} />);
	}
});

...

Hopefully this isn't too psuedo and sparse to be confusing! :P But basically propagating 'context' the library does now but not factory creating new classes on the fly (giving render the power to decide what to do dependant on 'current state') would solve all the issues and allow these forms to be used just like any other react component.

I tried to build v0.3 as you showed but I failed (I don't remember why though). I must find a few hours, sit down and reconsider the whole thing (maybe tomorrow or in the week end). Thanks for your insights, may I share my thoughts with you when I'll have something concrete?

Sounds good.
I'm going to try out a rudimentary version tomorrow for work. While it won't be as flexible for different templates etc. it should hopefully prove the concept!
Thanks for everything so far though!

@Chrisui  Some thoughts:

(leaf) components should be stateful: they must store the current value in their state in order to validate it when someone calls their getValue() method. Why? Because in general only the component knows how to validate a value and how to display an error. Besides, when you consider deeply nested structures, it would be hard for a top level component to handle the state / errors of children and children of children, etc...
because of 1. the components won't react to a value change from outside (via props change). The only solution I found is to implement componentWillReceiveProps

Experimental branch (v0.4):
https://github.com/gcanti/tcomb-form/tree/v0.4
It contains a simple prototype (only Form, Struct, List, Textbox components, not skinnable, no context, etc..)
This is a setup example:
var React = require('react');
var t = require('../.');
var debug = require('debug');
debug.enable('*');

var type = t.struct({
  name: t.Str
});
var options = {};
var value = {name: 'a'};

var Form = t.form.Form;

var App = React.createClass({

  componentDidMount: function () {
    // force re-rendering
    //setInterval(this.force, 1000);
  },

  force: function () {
  },

  getInitialState: function () {
    return {value: value};
  },

  onChange: function (value) {

  },

  getValue: function () {
    console.log(this.refs.form.getValue());
  },

  render: function() {
    return (

        <Form ref="form" type={type} options={options} onChange={this.onChange} value={this.state.value} />
        <button className="btn btn-primary" onClick={this.getValue}>Ok</button>
        <button className="btn btn-primary" onClick={this.force}>Force update</button>

    );
  }
});

React.render(<App />, document.body);

May I ask you to do some test with your use cases? Just to see if it's the right direction

I'll give it a go shortly! thanks!
Regarding the state I agree that each leaf should be responsible for it's own validation and storing local value. However I think that it should be allowed to work as a controlled input too.
So if you pass a value prop to the root Form component each leaf should take it's value from that (null if not present). This allows the state to be stored and updated easily from outside. Default initial values can be set with the defaultValue prop. If you omit the value prop you can use the component normally as you describe where state is local to each leaf.

So if you pass a value prop to the root Form component each leaf should take it's value from that (null if not present). This allows the state to be stored and updated easily from outside

The experimental branch should allow that behaviour. The key point is this check:
https://github.com/gcanti/tcomb-form/blob/v0.4/lib/components/Textbox.js#L27
In my tests I was able to update the value of a textbox from outside without losing focus.
The exception is the List component (now I remember why a I failed...lists are very, very tricky :)
https://github.com/gcanti/tcomb-form/blob/v0.4/lib/components/List.js#L28

Great seems to be working as expected using v0.4 branch!
What is the issue with lists? Might be able to help!

The main problem with lists is here (uploaded a new version):
https://github.com/gcanti/tcomb-form/blob/v0.4/lib/components/List.js#L107
If I use the counter i, React will try to reutilize the DOM elements when I swap two elements
(Up, Down button) resulting in weird behaviors
Example (with the previous setup):
var Person = t.struct({
  name: t.Str,
  surname: t.Str
});

var type = t.list(Person);
var value = null;
var options = null;

On the other hand if I use uuids (keys array) helping React to do the right thing I lose the possibility of having a controlled component since values and keys go out of sync if componentWillReceiveProps is called.
I'm working hard on this, hope to find a solution soon.

Now options and value are different properties.
What about the possibility to update the options from outside but not the value?

So if you pass a value prop to the root Form component each leaf should take it's value from that (null if not present). This allows the state to be stored and updated easily from outside.

Could you explain me why you'd want to update the value from outside. Shouldn't it be only controlled by the form?

@Chrisui I got it! Now there is a (painful) refactoring (code, tests and docs..) but it should be relatively
straightforward. I also spotted some possible optimizations.
Unfortunately there will be some breaking changes in the APIs.
Thanks so much for your help. Stay tuned!

@srconklin in the new version the re-renderings will be drastically reduced. I think it will solve your flickering issues

great.  I have been following the thread and can't wait for the new version.

Sounds great! I'll test it all out with my use cases when you think it's ready for it. :)
Sorry I'm only just replying! Needed to switch off for the weekend ;)

I'm writing unit tests right now: it ended up with a complete rewriting...

I'll test it all out with my use cases when you think it's ready for it.

Great! Thx

@Chrisui @srconklin
Ok, beta version uploaded on v0.4 branch. There are 261 tests at the moment, if you agree on the implementation and there are no problems I'll proceed to add more tests and final documentation / README.
Important note
Now form renderings are optimized, i.e. I implemented an aggressive shouldComponentUpdate.
https://github.com/gcanti/tcomb-form/blob/v0.4/lib/components/shouldComponentUpdate.js
In order to force an actual re-rendering you must pass in a different reference (=== is used) for at least one of:

type
options
onChange
value

Here's a bare setup to play with:
var React = require('react');
var t = require('../.');
var debug = require('debug');

debug.enable('*'); // shows when re-redenderings happen in the console

// showcase with all the relevant types
var Country = t.enums({
  IT: 'Italy',
  US: 'United States'
});

var Gender = t.enums({
  M: 'Male',
  F: 'Female'
});

var Person = t.struct({
  name: t.Str,
  surname: t.maybe(t.Str),
  gender: t.maybe(Gender),
  country: t.maybe(Country),
  rememberMe: t.Bool,
  tags: t.list(t.Str)
});

var type = Person;
var value = null;
var options = {
  fields: {
    gender: {
      factory: t.form.radio // this API fortunately is not changed
    }
  }
};

/*
  public API changed! t.form.create is gone. Now use t.form.Form

  <Form
    type="" required
    options="" optional
    value="" optional
    onChange="" optional

*/
var Form = t.form.Form;

// example of "uncontrolled" form (i.e. you can't change the form contents, focus is not lost)
var App = React.createClass({
  getValue: function () {
    var value = this.refs.form.getValue();
    if (value) {
      console.log(value);
    }
  },
  render: function() {
    return (

        <Form ref="form" type={type} options={options} value={value} />

          <button className="btn btn-primary" onClick={this.getValue}>getValue</button>

    );
  }
});

// example of "controlled" form
// (i.e. you can change the form contents changin one of type, options, onChange, value and force a re-rendering)
App = React.createClass({
  getInitialState: function () {
    return {value: value, options: options};
  },
  componentDidMount: function () {
    setInterval(this.force, 1000);
  },
  force: function () {
    console.log('forcing update...');
    this.forceUpdate();
  },
  onChange: function (value) {
    this.setState({value: value});
  },
  getValue: function () {
    var value = this.refs.form.getValue();
    if (value) {
      console.log(value);
    }
  },
  render: function() {
    return (

        <Form ref="form" type={type} options={this.state.options} onChange={this.onChange} value={this.state.value} />

          <button className="btn btn-primary" onClick={this.getValue}>getValue</button>

    );
  }
});

Hope it's all clear, let me know if you need more explanations.

Seems to be working perfectly for my use cases so far! I guess it's a good thing I have nothing more really to add ;)
Good work and thanks so much for spending the time on this. I'll be using it pretty intensively over the coming weeks so I'll let you know if I find any further issues...
Thanks again!

Awesome. I'll publish v0.4 on master, write more tests, update the docs, etc.. in the next few days.

Thanks again!

Thanks to you for pushing me towards the right direction.
Oh.. and before the next official release I expect from you a Pull Request regarding the "Contributions" section of the new README.md file ;-)

0.4.0-beta landed on master. All tests green with React 0.13.0-beta.1 :)

@Chrisui it's amazing what you can do now, try this one with the current version on master!

// change the form configuration on the fly based on form values

var Person = t.struct({
  name: t.Str,
  surname: t.Str
});

var Person2 = t.struct({
  name: t.Str,
  surname: t.Str,
  age: t.Num
});

var App = React.createClass({
  getInitialState: function () {
    return {
      type: Person,
      options: {
        fields: {
          name: {
            help: 'Type "a" to change the form configuration on the fly'
          }
        }
      },
      value: {}
    };
  },
  getValue: function () {
    var value = this.refs.form.getValue();
    if (value) {
      console.log(value);
    }
  },
  onChange: function (value) {
    // changes the form configuration on the fly!
    if (value.name === 'a') {
      // you can change even the type
      this.state.type = Person2;
      // change options
      this.state.options.fields.surname = {disabled: true};
    }
    this.state.value = value;
    this.forceUpdate();
  },
  render: function() {
    return (

        <Form ref="form"
          type={this.state.type}
          options={this.state.options}
          value={this.state.value}
          onChange={this.onChange} />
        <button className="btn btn-primary" onClick={this.getValue}>getValue</button>

    );
  }
});

React.render(<App />, document.body);

Yup it's basically exactly the type of thing I was trying to do! The power of stateful UI's!
After a week of developing everything seems to be working great!

Great. I'm going to release v0.4 soon. May I add you in the Contributions section?

Sounds great :)

ok, feel free to change what I wrote in the README.md file


ocamlPackages.gen: 1.0 → 1.1

Description of changes
Support for OCaml 5.0: https://github.com/c-cube/gen/blob/v1.1/CHANGELOG.md
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Is it supposed to build with ocaml 5.0?
I am getting the following:
$ nix-build --option sandbox true -K -A ocaml-ng.ocamlPackages_latest.gen 2>&1
this derivation will be built:
  /nix/store/y7zyzyyzp9gfi09s5jpd9r6v3g3zpc6a-ocaml5.0.0-gen-1.1.drv
building '/nix/store/y7zyzyyzp9gfi09s5jpd9r6v3g3zpc6a-ocaml5.0.0-gen-1.1.drv'...
unpacking sources
unpacking source archive /nix/store/3bviq3r9snsxz9mmah6b1pii87kn4i8d-source
source root is source
patching sources
configuring
no configure script, doing nothing
building
running tests
File "/nix/store/vl7fvzpl45s7hqrf00j6r0594m5xjx4w-ocaml5.0.0-ounit2-2.2.6/lib/ocaml/5.0.0/site-lib/ounit2/dune-package", line 24, characters 16-21:
24 |  (requires unix bytes seq stdlib-shims)
                     ^^^^^
Error: Library "bytes" not found.
-> required by library "ounit2.advanced" in
   /nix/store/vl7fvzpl45s7hqrf00j6r0594m5xjx4w-ocaml5.0.0-ounit2-2.2.6/lib/ocaml/5.0.0/site-lib/ounit2/advanced
-> required by executable run_qtest in qtest/dune:9
-> required by _build/default/qtest/run_qtest.exe
-> required by alias qtest/runtest in qtest/dune:13
(cd _build/default/qtest && /nix/store/9qdfdlnzx4kgk5jqpim1xkrmp31bcraw-gnumake-4.4.1/bin/make qtest-gen)
sh: line 1: which: command not found

Yes. As you can see in that log, it builds fine. Then tests fail because ounit2 is not yet compatible with OCaml 5.

Would it make sense to not run tests on OCaml 5 then?


Fix issue-opening action

Summary

In https://github.com/paketo-buildpacks/dep-server/issues/196, we saw an example of a workflow failure issue being reopened by GHA even though the dependencies of interest were different. This change makes it so that if an issue is reopened and/or commented on, the issue title must be what we expect it to be as well.
Use Cases

Checklist

[X] I have viewed, signed, and submitted the Contributor License Agreement.
[X] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[X] I have reviewed the styleguide for guidance on my code quality.
[X] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

Maybe it makes more sense to turn off comment_if_exists for the dep_server rep since the failures tend to be more heterogeneous? I think I'd find it confusing if the title of the issue kept changing  - then, previous failures on the issue wouldn't correspond to the title anymore.

@fg-j the implementation here is logically the same thing as adding a label, because the title has the dependency name in it. I like that failures in the same dependency will result in comments on the same issue.
I would like to change the workflow to stop reopening issue which is also what happened https://github.com/paketo-buildpacks/dep-server/issues/196, where an already closed issue was re-opened

@sophiewigmore My mistake, I now see what you were going for with the title comparison. I agree it's logically equivalent! See my inline comment about a bug in the implementation.

@fg-j fixed to search for the specific issue title


How to exclude an url to use in-memory-web-api

I'm submitting a ...
[X ] question about the decisions made in the repository

Hi, I am trying to develop with a real server, so I use angular2-in-memory-web-api. I follow instruction in this link from Angular.io. I had pass the tutorial.
But after complete config without error in console, I can not access url. Example for localhost:3000/app/heroes, it all redirects to main page and route to dashboard.
Of course I dont really know the in-memory works or not, but can not access or error in this url make me stuck.

I do not know much about the angular2-in-memory-web-api, but from what I can tell you may not have that route defined.
Can you upload your app.routing.ts and pages.routing.ts, in one of which you should have your route defined?

I think I will drop this, because many things will be changed. Angular-CLI will support web-pack or something like that, so not waste effort for this.
I choose to use a real api server for now. Thanks.


Swarms become invisible

Hi there,
I am encountering issues with the swarms becoming invisible to my camera at certain points when my scene is running. I am animating the swarms and moving them around. Have you dealt with this issue before?

I guess that it disappears because of inaccurate frustum culling. I wonder if it could be resolved by expanding the bounding box.
https://github.com/keijiro/Swarm/blob/master/Assets/Swarm/CrawlingSwarm.cs#L271

Thank you, I will try this. The Swarm I am using is the Floating Swarm. I will report back how this goes.


cache doesn't fail when it fails

This cache module is giving me a very hard time and I am honestly thinking, mostly because of the sub par cache support and speed in GH Actions, that we wont stay here for much longer.
That being said: we lost a lot of built-minutes (and therefore money) in the past month because of mainly two already recognized problems:

sth like [warning]connect ETIMEDOUT <IP_ADDRESS>:443 https://github.com/actions/cache/issues/141

[warning]No scopes with read permission were found on the request. https://github.com/actions/cache/issues/208

Both do not let the steps fail, therefore our jobs continued and failed much later. While this is super annoying and expensive, I'm really wondering if you couldn't at least implement a quick fix for this to fail, so we don't pay so much money for errors that were thrown as warnings.

@boredland I think a quick fix is to change line 107 in restore.ts from
utils.logWarning(error.message);

to
core.setFailed(error.message);

Would you be able to share your workflow file?  If the cache is failing to restore, you should be able to conditionally run a step to recreate whatever was put into the cache:
  - name: Restore content after cache miss
    if: steps.cache.outputs.cache-hit != 'true'
    run: ...

Depending on what you're storing, you could also consider using workflow artifacts.  Workflow artifacts are designed for data you want persisted longer and must be retained, whereas the cache is best effort and caches can be evicted at any time.

Hi! Thanks for looking into this. The workaround with a subsequent step that fails when there is no cache hit, I already added.
Regarding workflow artifacts:
In fact I am using the cache as an artifact, mainly because of its ability to save across multiple paths. We are inside a lerna monorepo. Some packages need to be built as dependency for others. Caching them saves me some precious build-minutes.


[compiler] Distribute labs/compiler decoupled from any specific toolchain

Originally posted by @filimon-danopoulos-stratsys in https://github.com/lit/lit/discussions/4117#discussioncomment-7402453
I would like to discuss the possibilities of distributing this in other ways than a TS-transform and rollup plugin (as mentioned in the RFC). Not having an option to transform a single file without additional tooling makes it hard or impractical to use the compiler in esoteric or custom build environments. The immediate issue is that it is not possible to use the compiler with esbuild and in extension Vite in development mode.
It seems to me that the compiler should be standalone and not force consumers to use a certain toolchain that depends on TSC. What would the practical implications be if this was to be implemented without the requirement of TSC?
Concerning providing plugins for other tools, one alternative would be to use some thing like https://github.com/unjs/unplugin. Seems like it should be fairly simple to build given that a transform function for a single file is available.

This is an excellent idea! It could also be a great contribution!
The labs/compiler tests already test both TypeScript and JavaScript input files, and do the single file transform via TypeScript's ts.transpileModule method: https://github.com/lit/lit/blob/main/packages/labs/compiler/src/test/golden_compiler_test.ts#L65-L71
This single file transpile implementation could be exported, wrapped as a function implementing the rollup transform API (which would then be compatible with unplugin). Source maps can be retrieved from ts.transpileModule by passing in sourceMap: true into the compilerOptions.
The pro of this approach is it's easy given what we have. The con, is that we also run all the other TypeScript transforms on the provided JavaScript source code. We may need to adjust the compiler settings for JavaScript files so only the templates get transformed, and nothing else.
Is there a set of compilerOptions that we can give ts.transpileModule that won't change anything else? Does it matter if some stuff minimally is changed?
How is JavaScript using different modules handled (commonjs, amd, umd)?

The main drawback I can see (if I understand it correctly) with the proposed approach is that the Lit-compiler would essentially act as the TS-compiler for the affected files. Instinctively this seems odd. I would preferably have a solution that accepts either JS or TS and outputs the same language with only the relevant Lit optimizations applied.
That way any third part tool would essentially still be in control of how to transpilation is performed.
I don't have enough experience with the TS APIs used to know all the details but at a glance it seems mostly straight forward to use something like the @babel family of packages and reuse a lot of the code that already exists. Only reason I mention them is that I have worker a bit with them before. Unfortunately not enough to be able to make an objective comparison.

Same Filimon answering, this is just my private account.
Running the compiler in the way you suggested above seems really expensive if applied to every single file in a project. Probably enough to negate the use of faster tools, like esbuild.
Missed that you mentioned module types, I think it is fair to restrict the compiler to modern code, so code written with ES module syntax. This would also mean than any compilation would have to be performed before additional transpilation happens (or simultaneously). I don't see any benefit to allowing other module types.
I have been reading up a bit on the tools provided with typescript and I think it would pretty easy to just change what API:s are used and still keep a lot (probably all) of the same AST-related code. Granted it would require substantial changes to the code overall so before doing anything I would like some inputs on goals and limitations.
What was the driving factor of creating the compiler as a TS transform rather than a function that applies the compilation? Would it be in the spirit of compiler project to change this?

I don't see any benefit to allowing other module types.

Agree

What was the driving factor of creating the compiler as a TS transform rather than a function that applies the compilation?

The driving factor was to target a known "first user" of the compiler (internal Google code). This was to target a known user who can benefit from the work. This also gave a large test codebase to be able to ensure the compiler is working as intended. Internally, there is an easy way to add a TypeScript transform to TypeScript compilation so that shaped the initial public API.
The other hope was that TypeScript would make it easier to add custom transformers natively. This would still only target TypeScript users, but it would avoid the issues with toolchains. https://github.com/microsoft/TypeScript/issues/54276
Our team is also familiar with the TypeScript API, and it's convenient that it handles things like source maps.

Would it be in the spirit of compiler project to change this?

I think so. Although in my mind we'd probably end up extending it. The current implementation already conforms to the following constraints (which would make writing a JavaScript (ESTree) version easier):

We do not allow using the TypeScript compiler to perform type checking based transforms. It's syntactic only.
The transform must work at the file-level. There is no way to look across files.

I would still like to expose a TypeScript transform, but we could have a second ESTree based transform backend which provides a generic function for applying the Lit compiler transformation to a JavaScript file. The test suite could be shared as well between backends.

I don't have enough experience with the TS APIs used to know all the details but at a glance it seems mostly straight forward to use something like the @babel family of packages and reuse a lot of the code that already exists

Agree. The general structure of the compiler currently is:

Iterate over the whole file's AST and find Lit templates. Found templates get remembered for the next pass.
Iterate over the whole file's AST again, but now rewrite these located templates to the compiled template. This code is mostly agnostic to the AST, it uses parse5 to implement lit-html's prepare render phase.

I need to think more deeply about where would be a good abstraction boundary which could allow for both node types, but from a quick search there seems to be a mapping between TypeScript and ESTree nodes.
tl;dr: Currently I'd love the TypeScript transformer export to remain, and I think we could also expose a JavaScript solution by extending the codebase to also traverse and analyze an ESTree based AST.

Keeping the transform seems reasonable, there is no objection in that regard from me.
Why would switching between the TS AST and an ESTree AST be required? I think the tools from the typescript package would work fine.
I have had a bit more time to read the code  after familiarizing myself with the TS API. If I am not mistaken what I was initially interested in would be a simple extension to the existing API.  I have a hard time putting this into words so here is some code to illustrate what I am after.
function optimize(fileName: string, code: string): string {
  const file = ts.createSourceFile(fileName, code)
  const result = ts.transform(file, CompiledTemplatePass.getTransformer()
  const printer = ts.createPrinter();

  return printer.printNode(
    ts.EmitHint.SourceFile,
    result.transformed[0],
    ts.createSourceFile('', '')
  )
}

The approach above seems to handle JS, I did a small verification in isolation with a rudimentary transform
import ts from 'typescript';

const code = 'const foo = html`
Test
;';
const file = ts.createSourceFile('test.js', code);

const transformFactory = context => root => {
  const visit = node => {
    const currentNode = ts.visitEachChild(node, visit, context);
    if (ts.isIdentifier(node) && currentNode.text === 'foo') {
      return context.factory.createIdentifier('bar');
    }
    return currentNode;
  };
  return ts.visitNode(root, visit);
};

const result = ts.transform(file, [transformFactory]);
const printer = ts.createPrinter();
const transformedSource = printer.printNode(
    ts.EmitHint.Unspecified,
    result.transformed[0],
    ts.createSourceFile('', '')
  )

console.log(transformedSource ); // prints: const bar = html `<div>Test</div>;`;

I would be in favor of a very simple addition in the spirit of the code above. It does require a typescript dependency even for non-TS users but any other solution would require another dependency. Something like proposed solution does not however depend on any tsconfig.json.
Sorry for not doing enough research before hand, seems I spoke to early and wasted a bit of time.

I like you optimize example, and is along the lines of what I was thinking about regarding using ts.transpileModule(...).
Which could look like:
function optimize(_fileName, source) {
  const result = ts.transpileModule(source, {
      compilerOptions: {
        target: ts.ScriptTarget.Latest,
        module: ts.ModuleKind.NodeNext,
      },
      transformers: {before: [compileLitTemplates()]},
    });
    return {code: result.outputText, map: result.sourceMapText};
}

The primary benefit and why I initially thought about this API is that it handles source maps. The negative is that it has less fine grained control over the transforms applied than your example.
I bet there is a way to manually add source maps to your better example. Thank you for brainstorming with me.

It is possible to pass compiler options to .transform , including sourceMap: true but I don't see am obvious way to extract any source maps.
I guess the transforms are simple enough that creating the sourcemaps manually is an option but it does require substantial additional effort. Additionally it scales quite poorly with additional complexity in compilation. I don't think I can be of much help in figuring out how this is best done as I don't really have a good grasp of the tooling and I can't find any documentation apart from the source.

Whats a little unfortunate about using transpileModule is that is also does other transformations. Ideally I'd have some kind of function, like litCompiler(sourcecode) that I can run on a string of source code, and have it only do the lit-relevant transforms.

Another option to the ts.traslate route would be to to use something like https://www.npmjs.com/package/magic-string
The AST traversal could then identify what segments of the text to alter but the actual altering of the text would be done through magic-string. The current set of transforms are simple enough that this seems an easier route than generating source maps manually.
I am pressed on time for this but I could attempt a POC based on this approach if it is of interest. Is there any particular policy regarding third party tooling to consider?

I have played around with magic-string as an alternative to do the transforms but it creates more problems than it solves in compared to just building the source maps manually. I got a bit more acquainted with the transforms the compiler makes and they are pretty straight forward to create the soucemaps for.
Additionally, creating the source maps manually allows all code in regards to the transforms to remain the same. I can maybe attempt a PR if you are interested.

Thank you for investigating. I am interested!
It sounds like this would give us a path forward to provide the optimize function you proposed, whilst also exporting source maps! That seems like a clear win!


neon-cli is including ASPNETCORE components which is bloating the install by 16MB

One of the libraries must be referencing this by mistake or we need a new library for ASPNET stuff.

I poked around this for a bit and removed some ASPNETCORE related package references in the solution but that's still not helping.
It looks like all of these additional files are brought in when publishing the app.  I'm still not sure why these are being referenced, so more research to do.
I wonder if it might be possible to just delete these files when generating the installers.

I finally figured this out.  The problem is that the Neon.Kube.csproj project is referencing the NSwag.MSBuild package for some reason:

This must be bringing ASPNET in.  I'm going to remove this.

FIXED

This is still a problem.  I've used the divide-and-conquer technique and narrowed this down to Neon.Kube.Setup.
The problem is that this project is referencing Neon.Kube.Operator.  That assembly is only intended to be referenced by actual operator services, not other libraries or non-operator applications because it will bring in ASP.NET and potentially other junk we don't need.  Non-operators will reference Neon.Kube.Resources to use CRDs generated by the operator.

Actually FIXED


Get mandatory api

Add GET /transaction/{hash}/mandatory to retrieve the list of mandatory recipients for a given transaction hash.
This is to support contract extension operation

LGTM


Implemented parallel downloads in batch step

This PR adds the use of coroutines in the batch step to facilitate parallel download and processing of report files.
Test Steps:

Set debug level logging in src/main/resources/log4j2.xml (line 31)
Run smoke tests on this feature branch
Observe logs for Starting download for blobUrl and corresponding Finished messages. You should see multiple downloads start in parallel.

Changes

BatchFunction.batchUniversalData() and WorkflowEngine.createHeader() now make use of runBlocking, async, and awaitAll to enable parallel download and processing of reportfiles.
Added debug level logging for individual downloads; info level logging for aggregated duration of downloads

Checklist
Testing

[x] Tested locally?
[x] Ran ./prime test or ./gradlew testSmoke against local Docker ReportStream container?
[ ] Added tests?

Linked Issues

#10692

To Be Done

Logging
Test instructions (in this PR)

@thetaurean please update PR description with ticket you are fixing

After a quick huddle I suggested that we create a new bug ticket (#11370) to explicitly call out the double download bug.
This could have probably been kept in the same branch/PR but I also didn't want to further delay merging this since it can impact production.


Combination crafting does not work with very high energy values

This is a bug I've encountered on the normal mod version aswell, but if an item made with combination crafting requires a very large amount of energy in total to craft (i assume the limit is 2.147 billion), the item will never finish crafting, it will just forever keep using energy. Using Integrated Dynamics to read the nbt of the crafting core quickly, it is possible to see that the 'Progress' value constantly switches between negative and positive numbers, which I assume is because of the integer limit.

Can you post an example of a script that adds such a recipe, and describe the setup: for example, how are you supplying power? I'm wondering if this is just an overflow as you transfer too much power at once.

Yeah, no, looks like it's just that recipes support cost up to long limit
https://github.com/OmnifactoryDevs/ExtendedCrafting/blob/7a1f8c36853880ea9eaebfbebb4b094eec0eef4e/src/main/java/com/blakebr0/extendedcrafting/crafting/CombinationRecipe.java#L16
but the tile is only storing its own power as int
https://github.com/OmnifactoryDevs/ExtendedCrafting/blob/7a1f8c36853880ea9eaebfbebb4b094eec0eef4e/src/main/java/com/blakebr0/extendedcrafting/tile/TileCraftingCore.java#L40
In Cucumber
In Forge

wouldnt it just be that this variable has to be changed to a long?
https://github.com/OmnifactoryDevs/ExtendedCrafting/blob/7a1f8c36853880ea9eaebfbebb4b094eec0eef4e/src/main/java/com/blakebr0/extendedcrafting/tile/TileCraftingCore.java#L42
since further down at
https://github.com/OmnifactoryDevs/ExtendedCrafting/blob/7a1f8c36853880ea9eaebfbebb4b094eec0eef4e/src/main/java/com/blakebr0/extendedcrafting/tile/TileCraftingCore.java#L147
from what im understanding its just subtracting the progress value which increases every tick by the energy that the recipe consumed from the total recipe energy cost, until it reaches 0, but since progress isnt a long it will overflow at over 2b and thus if the total energy cost is over that limit it can never subtract enough to bring it to 0 and finish, and if it was a long it could do that, right?


curve_fit(method!="lm") ignores initial guess

Briefly, the addition of least_squares functionality into curve_fit contains the following lines
    else: # if method != "lm"
        p0 = _initialize_feasible(lb, ub)
        res = least_squares(func, p0, args=args, bounds=bounds, method=method,
                            **kwargs)

i.e. p0 is not used when determining the initial guess (also confirmed the behavior on actual tests).  I'd think you only want to call _initialize_feasible if p0 is not passed, and raise a ValueError when a non-feasible initial guess is given.
@nmayorov @ev-br

Good catch Antony! This is a release blocker.

It is a strange mistake indeed.
I personally think that curve_fit is not very good function, because it hides important options and encourages usage of least-squares optimization without analytical Jacobian. Ceres authors also advise not to do this http://ceres-solver.org/faqs.html#modeling Because of that I did this integration at the last step and without much interest.
Can you please send a fix for this? Would be great if you also cover #5068 (perhaps in a different PR).
I'm sure it will be merged faster than your doc PR, where we stuck (temporarily) on this renaming issue.

I'd think the patch comes down to
if p0 is not None and not np.all((lb <= p0) & (p0 <= lb)): raise ValueError.
(except that p0 has already been given a default value at that point so you need to stash somewhere whether it has been defaulted or not yet).
Turns out I have a few other things on my plate now, so it's not even clear I'll have time for the doc PR :(

fixed in gh-5722


What form does your personal Creative Commons toolkit take?

The personal toolkit is mentioned here.

Select two or three resources directly relevant to your personal or work-related CC needs from the Acquiring Essential Knowledge content and add them to your personal Creative Commons toolkit.

As someone who is following the Unscheduled Informal delivery format, what should I do, especially if I am thinking of transitioning to a Formal format to obtain certification?

AH! Just read the blog post - The Toolkit is conceptual at present.


Publish retained messages only after connack

Alternative to #143 / #144

Ensure retained messages on inherited subscriptions are only published following the Connack packet.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

4 of 4 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.0008%) to 98.656%

Totals

Change from base Build<PHONE_NUMBER>:
0.0008%

Covered Lines:
5066

Relevant Lines:
5135

💛  - Coveralls

@thedevop

Looks good!

@thedevop - I have a concerns about the use of true for the existed parameter. Please check my reasoning:

A client subscription can be inherited from a new client from an existing client.
A new client cannot subscribe before inheriting a subscription.
Therefore, a new client cannot have any existing subscriptions.

Therefore, the value for existed in inheritClientSession must always be true, as the subscription already existed on the client being inherited from.

If so, then the logic if !existed { atomic.AddInt64(&s.Info.Subscriptions, 1) } in inheritClientSession must also be impossible to reach, and therefore serves no purpose.

Does this sound correct?

I didn't look into the Topics.Subscribe before, but you're correct, since these are inherited subscription from the same clientID, therefore it should always be existed.


Evaluate cannot feed value of shape to tensor with shape

Hi,
as I wanted to try out your programm i did first train it. Then i wanted to evaluate my training after a few minutes. But as it wants to load the images into the feed_dict it says the following:
Cannot feed value of shape (500, 334, 3) for Tensor u'image_placeholder:0', which has shape '(1, ?, ?, 3)'
I acutally fed the same images i used for training. What am i doing wrong here ?

just add an extra dimension to your image before feeding using
import numpy as np
image = np.expand_dims(image,axis=0)

okay thank you that worked. But now the eval.py saves numpy arrays in the save_preds directory ? Is this working as supposed ? How can i converte these numpy arrays into pictures ?


chapter 13, test wrong be wrong

I follow the command to code , when I test,
For example, visit http://localhost:3000/dashboard/invoices/2e94d1ed-d220-449f-9f11-f0bbceed9645/edit.
fetchInvoiceById
console.log(invoice); // Invoice is an empty array []
it has not catched the non- id
Then it go to
app\ui\invoices\edit-form.tsx (21:63) @ id
19 | customers: CustomerField[];
20 | }) {

21 | const updateInvoiceWithId = updateInvoice.bind(null, invoice.id);
|                                                             ^
22 | return (
23 |
24 |

I wonder it has not catched the wrong
code at https://github.com/liwenz/nextjs-dashboard   chapter  13 finish sth wrong

I change it as follow:
console.log(invoice[0]); // Invoice is an empty array []
then 404 catched!

throw new Error('Failed to Delete Invoice');
works fine at first, but later:
app\lib\actions.ts (75:8) @ deleteInvoice
73 | export async function deleteInvoice(id: string) {
74 |

75 | throw new Error('Failed to Delete Invoice');
|      ^
76 |
77 | try{
78 |   await sqlDELETE FROM invoices WHERE id = ${id};

is the grammer wrong?

Hey there, I'm sorry but it is not clear what the issue is here. Are you still seeing this? Could you provide more details? The test appears to be correct in the chapter.


Drop usage of permission fields entity_*

Part of https://github.com/CartoDB/cartodb/issues/7013
This PR removes the use of entity_id and entity_type fields from the Permissions model. This is to be run after the rake in #7015 but before the migration that actually drops the fields (WIP).
As the Permission model needs the visualization for several operations, the entity family of methods have been replaced to search the corresponding Visualization by checking the permission_id column of the visualizations table. This field is already indexed, so queries should be fast.
This also introduces a restriction on Permission creation. As permissions will be created before visualizations, the visualization will not exists at creation time. This means that no permissions can be granted at creation time (ACL must be empty), only after the visualization has been created.
There is no place in the code base that does this, all visualizations are created with default permissions, and there isn't an API for permission creation. Some tests did, and have been modified so permissions are created empty and then updated. A validation has been added to check for this, to avoid exceptions when saving.

Ready for review! Can you CR @juanignaciosl?

Code looks :ok_hand: after your last commits, but please check dataset and maps sharing at staging :sweat_smile:


Added left to right menu opening support

Hi,
I added support in left to right menu opening. also added basic infrastructure for future support in menu opening below the button.

Hello @tomhoffen,
thanks for your great work! I will test everything tomorrow morning and merge this one if there are no problems.
Thanks again!

Hi,
There is on issue for now.
The center is calculated in getMenuDirection.
For now it takes the center of the superview.
I think that it should take the center of the screen.

@tomhoffen yes, i think center of the screen will be better


Add config option to enable uws

This enables support for uws in the gameserver.ini configuration file. Closes #158

it's not good idea to commit code formatting with some code change. Because it's too hard to understand what really were changed
did you noticed that sendPacket code were changed? and this change was removed in your pool request

it's not good idea to commit code formatting with some code change. Because it's too hard to understand what really were changed

Pretty sure Github does this crap by itself,

@Barbosik I'm sorry but my text editor decided to format this on its own. and the latest sendPacket code wouldn't work with uws because _socket does not have a writable property in uws.

then there is need to find how this property is named in uws and how to get it. Because removing such check will leads to lags

You shouldn't use writable in the check, that's not needed and I cannot see any reference of its usage in the documentation. Any net.Socket is always writable, you only need to check the readyState. If you want to hinder any accumulation of unsent messages you need to use the send callback:
ws.send(buffer, {binary: true}, callback);
This callback is called when the buffer has been consumed. Use that to check if what you sent got consumed before you send anything more.

@alexhultman: this check was added to check if socket is in closing state. It allows to reduce send errors. Without this check the log is spammed with errors, such as 'This socket has been ended by the other party', 'This socket is closed.' and other.
For example:
[ERROR][03:20:18] [<IP>:58400] Error: This socket is closed.
    at Socket._write (net.js:635:19)
    at doWrite (_stream_writable.js:223:10)
    at writeOrBuffer (_stream_writable.js:213:5)
    at Socket.Writable.write (_stream_writable.js:180:11)
    at Socket.write (net.js:613:40)
<...>

It also allows to check if the connection is closed before build packet (when close event still not emited)

That's really strange how you manage to get a conflicting report from readyState (OPEN), yet have a closed net.Socket. In any case, you don't need to check this in uws - if readyState is OPEN the socket is guaranteed to be writable, so you could change that check to something like:
if (uws_is_the_ws_module || writable_check_here) {
}

@alexhultman: it's bad if closed connection is writable, because it will leads to useless cpu load to build packet for closed client. Each client eats some significant cpu time, because it needs to lookup for visible cells, build packet, etc. It's better to skip these actions on close connection as soon as posible

Yes, but my point is, in uws you will never get readyState == OPEN on a closed socket. If you get readyState == OPEN, the socket is open.

https://developer.mozilla.org/en-US/docs/Web/API/WebSocket#Ready_state_constants
readyState == OPEN should always mean the socket is writable. How you manage to get ws to report the socket to be OPEN, yet the net.Socket is closed is probably due to something strange in the usage.

ok, it's good solution

@alexhultman: How you manage to get ws to report the socket to be OPEN, yet the net.Socket is closed is probably due to something strange in the usage.
it's just ws implementation. It reports readyState == OPEN, but attempt to write fails. Usually it doesn't happens on dev environment. But it happens very often when there are a lot of real connections.
The bad thing is that it fails inside ws code for read operation, and I cannot prevent it:
[ERROR][08:41:51] [<IP>:52823] Error: read ECONNRESET
    at errnoException (net.js:901:11)
    at TCP.onread (net.js:556:19)

@alexhultman @Barbosik  This almost seems like a bug with ws itself. Should I check if we are using ws and if _socket is writable? That would seem to fix this issue.

Yeah just ignore that check with uws

I believe I have fixed this issue.

@Barbosik @alexhultman Might there be anything else that needs to be changed before this can be merged?

@henopied That's awesome, now I can get it to work :). However I think the configuration is broken, I wasn't able to swap to uws via the config but had to hardcode the require. You can check what implementation is running by opening developer tools in Chrome and Network and check the response headers of the WebSocket connection. It will say Server: uWebSockets if uws is running.

My bad, it works. I edited the wrong gameserver.ini...

I am developing something random using uws on Windows.  It seems that uws only works on Node v6.3.0 and above.

@SimonOrJ Luckily uws has an almost identical api to ws so you can swap them easily.

Merge? The reported issue is not caused by this PR but rather by the _socket getter failing on closed sockets in uws. This will be fixed in uws itself so nothing about this PR.

there is an issue with installation. I cannot install uws.

What issue?

I tried to install it on windows machine, if I understand correctly, it requires npm package windows-build-tools. When I executed npm install windows-build-tools it starts to download a bunch of megabytes with different exe, msi, etc. After 30 minutes of installation it just hung.

These windows-build-tools install failures are Microsoft's problem, it's their broken package.

Btw, as soon as _socket#writable is added to uws it will be used as my pr checks if it is defined not if we are using uws.

If you use Node version 6.3.0 and higher, then uws will work without having to go through compiling issues.  It doesn't work with windows-build-tools anymore.

There's now 0.7.9 which fixes #219

Btw, if you make uws default I can link to this project from front page.

merged


Shall --exclude-loopback affect "localhost" as well?

Currently using the -E option does not exclude the localhost hostname, which I somehow expected.
Strictly seen this is correct, as the option aims to exclude the "loopback IP address range" explicitly, while localhost is only a common local hosts entry pointing to the loopback IP, while it can point to anything else or not exist at all.
So just the question whether it does make sense to still affect localhost as well, or whether to have an own option for it (probably doesn't make sense as a single --exclude does it) or have it implied with -E, --exclude-all-private?

@pawroman what do you think?

loopback is determined by std's function https://doc.rust-lang.org/stable/std/net/enum.IpAddr.html#method.is_loopback
which already includes <IP_ADDRESS>
https://doc.rust-lang.org/stable/std/net/struct.Ipv4Addr.html#associatedconstant.LOCALHOST

By RFC 6761, localhost is reserved for loopback purpose.
https://datatracker.ietf.org/doc/html/rfc6761#section-6.3
So the only correct way of handling it is to follow std and the standard, that treat it as loopback.

By RFC 6761, localhost is reserved for loopback purpose.

The wording isn't actually that strict.

Name resolution APIs and libraries SHOULD recognize localhost
names as special and SHOULD always return the IP loopback address
for address queries and negative responses for all other query
types.  Name resolution APIs SHOULD NOT send queries for
localhost names to their configured caching DNS server(s).

It's SHOULD and not MUST 😉. On the Linux distros I work, it is practically a "must", as a whole lot of software simply requires and expects it do be like that, but I'm not sure if it is that clear on all OSes 🤔.

https://datatracker.ietf.org/doc/html/rfc2119#section-3

that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

Should 'localhost' be treated differently from std and RFC, it'd be against most peoples expectations.
If its really needed, we can add one more configuration option. that's much better than breaking the principle of least surprise

Don't understand me wrong, I'm clearly on your side in this, which is the reason why I opened the issue. Just for completeness and understanding possible implications, it needs to be taken care that there is a difference between an IP, which is somehow absolute and via MUST bound to specific purposes, and practically it is impossible to access a remote host directly (without redirection, embedding etc) with any loopback/LLA/private IP address. But there are no such MUST bound strict rules for hostnames, and also practically one can make localhost point to any random remove host via hosts entry. But I agree that it will meet "most peoples expectations" (including mine) to imply localhost in loopback exclusion. Any different hosts entry, at least on all systems I know, could be seen as wanton destruction 😄.

I'd accept a PR for adding localhost to the exclusions when using -E. Bonus points for adding some documentation on the reasoning and a link to the RFC. Any takers?

Shall it be with the -E flag only, or with --exclude-loopback already, since it practically is the loopback address?

Let's do both, yeah. Would you like to tackle this?

I cannot guarantee that I find time soon, but I'll have a look into it. So far I cannot imagine that it's hard to implement, even for a Rust newby like me 🙂.

PR up: #351


chore: adaptations for nightly-2024-02-15

For someone who has not been watching the progress of the lean4 PRs, what are the changes? It is very difficult to review this since these files have been moved to core with unknown modifications.

For someone who has not been watching the progress of the lean4 PRs, what are the changes? It is very difficult to review this since these files have been moved to core with unknown modifications.

The main downstream visible changes are in module structure.  Tactics that previously required an Std module import that are migrated will be available without import.  Similarly definitions in Std.Tactic are getting moved elsewhere (Lean.Meta.Tactic).
We'll aim to provide guidance on what has changed in the next release.

I agree with @digama0. Where should be guidelines for move PRs since these tend to be big and hard to review.
One general principle should be that moves should minimize changes to the bare essentials (imports, namespaces, for example), and later PRs should be used for any other changes.
Another principle is that when moving away, all additions should be explained somehow, probably in the PR description.

The import additions are to just to keep declarations in scope.  We'll probably need to shake the imports further.  The only other move of note I see is Bool.eq_iff_iff from Std.Logic to Std.Data.Bool and that's largely because most of the contents of Std.Logic have been ported to Lean itself.
To the extent there are changes; it's largely happening within the Lean repo as we adapt Lean to address inconsistencies between Lean and Std (e.g, soon Lean master will use ediv/emod for Int division).
I appreciate this is really hard to review (and even just track).  We are trying to improve the consistency of new user experience across Lean, Std and Mathlib and are focused on getting tactics (including omega) and dependencies needed for tactics upstream rapidly.

To the extent there are changes; it's largely happening within the Lean repo as we adapt Lean to address inconsistencies between Lean and Std (e.g, soon Lean master will use ediv/emod for Int division).

This is my concern. Not so much the moving / import changes, but rather the little changes that happen after that in order to make the code "fit" inside the Lean package better. I would like those changes to be explicitly recorded and tracked in the relevant PRs, and/or avoided if at all possible, because as things stand I have no idea if this broke backward compatibility and what mitigations we need to apply because of it.

I concur again with Mario. Moves should have a "move-point" after the basic move and before any adaptations. I don't think it is necessary for the "move-point" to compile, so long as the errors make sense and are fixed in adaptation PRs. This is complicated but I think this is necessary, I've moved several times in my life and it was always complicated: 😟 🚚 😟 🚚 😄


Lack of license

I'm confused under what license this layer is distributed, would be happy to see LICENSE file as in other your repos

https://github.com/tuxable-ltd/meta-scikit-learn/commit/efb26c7b1878dca5395b19cc240a71c9a24b924d
Thanks!


I have a problem in the process of cross compiling

issue:./include/dmlc/./optional.h:67:29: error: 'class dmlc::optional' has no member named 'val'
std::swap(val, other.val);
I should how to modify?

@sandeep-krishnamurthy Can you please add labels:

ARM
Pending Requester Info

Also, 30+ day old issue. Please close the issue due to inactivity and no response from the requester.
@zhangguotai Please follow this template when you are creating an issue in future since this will help the community to identify the issue faster.
If done in error please feel free to re-open and comment.
Thanks!


Not keeping track of validation set performance during training?

Is there a reason the current version of the training script does not appear to keep track of validation set performance during training? It seems data_gen_val is defined but no longer used, is this an oversight perhaps?

I believe it is used when measuring the mean average precision (mAP)

I was asking this myself - so far I did not find out where it is used

This is an oversight on my part and should be added as an option (since it can be kind of time consuming and the original implementation didnt have it)

Related issues: #172, #165


CMake Targets Split

Splitting the project into multiple CMake targets to seperate the Engine specific code from the game specific code, and for proper testing

 Additional Changes

 Additional Changes


fwupd: 1.1.0 → 1.1.1

Motivation for this change
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: fwupd
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: fwupd
Partial log (click to expand)
shrinking RPATHs of ELF executables and libraries in /nix/store/i6q968r8r036khismi01p4p6bmb4fxwj-fwupd-1.1.1-man
gzipping man pages under /nix/store/i6q968r8r036khismi01p4p6bmb4fxwj-fwupd-1.1.1-man/share/man/
strip is /nix/store/gpc2wld1s0c6qzx9326cwn1wcx29xzsj-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/i6q968r8r036khismi01p4p6bmb4fxwj-fwupd-1.1.1-man
checking for references to /build in /nix/store/i6q968r8r036khismi01p4p6bmb4fxwj-fwupd-1.1.1-man...
shrinking RPATHs of ELF executables and libraries in /nix/store/j9g25gxkirp0b7hv3jh1xixds7q431xw-fwupd-1.1.1-installedTests
strip is /nix/store/gpc2wld1s0c6qzx9326cwn1wcx29xzsj-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/j9g25gxkirp0b7hv3jh1xixds7q431xw-fwupd-1.1.1-installedTests
checking for references to /build in /nix/store/j9g25gxkirp0b7hv3jh1xixds7q431xw-fwupd-1.1.1-installedTests...
/nix/store/n2h2gxp8681fzjyk86nr50qfzcy29a6n-fwupd-1.1.1

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: fwupd
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.


[Doc] Fix minor issues in RN

What type of PR is this：

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[x] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

run starrocks_admit_test

run starrocks_be_unittest

run starrocks_clang-format

@mergify backport branch-2.4 branch-2.5


fix: page index evaluator min/max args inverted

Fixes :https://github.com/apache/iceberg-rust/issues/647
I didn't catch all the places where I needed to change the order of the min / max args in an earlier refactor.
Added a few more tests to ensure this is covered properly. Also updated the other scan tests to ensure that they enable row selection as well so that this code path is covered in all of the scan tests.

@liurenjie1024 / @Xuanwo - would you be able to review this bug fix please? Without it, in some situations we return incorrect results when row selection is enabled. Thanks 😁


Sqlite backend

Hi
This code implements a SQLite backend to persist scheduler state across reboots.

Just my opinion:
would it be possible to abstract a storage (set of generic functions as protocol) in a way that the user of 'scheduler' could choose from maybe different storages? Maybe a separate .asd for SQLite?
I'd not want to pull the SQLite dependency when I have another database already in the project.

That is a good idea. I can make this fit into such a scheme if someone comes up with it.

I can check what behavior you have towards the storage. Didn't look closely. Let's see.

Isn't that already abstracted? You scheduler implementation implements the required generic functions.
So I think it would be more or less just separating this into a dedicated .asd, no?

The split between the scheduler and scheduler-implementation packages makes it tricky to add another system and package. I will look at this again at another time.

from other remarks: please squash commits so they are:

commit1: introduces the new code
commit2: updates the readme

thanks for improving the pull request, I did another pass of the review and had some remarks. Please see above.

Hi
Sorry about the noise. I was not done yet, just pushed for backup. I will have to study Github's idiosyncrasies better.
Thanks for the feedback. I will look at it.
--
www.darkchestnut.com - Common Lisp blog
On Mon, May 2, 2022, at 08:59, Daniel Kochmanski wrote:

thanks for improving the pull request, I did another pass of the review and had some remarks. Please see above.
—
Reply to this email directly, view it on GitHub https://github.com/sharplispers/scheduler/pull/5#issuecomment-1114553178, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3ZDHR6D4N25LDOR6DERUTVH54NXANCNFSM5KKXXX6A.
You are receiving this because you authored the thread.Message ID: @.***>

Apologies about all the single commits. How do I squash them?
Otherwise I think I address all the comments except the :NAME parameter.

I've pushed a branch task-designators to the repository that refactors some code (most notably extracts tests into a separate system) , if that's not much of a bother then you could rebase against this branch.
Regarding how to "merge" commits, the usual way is to
git rebase -i task-designators # or master

and squash commits onto the first one.
finally
git push --force

I will look at this again another time.


Implemented support for using DBFlow in shared libraries

This PR contains the patch for using DBFlow in shared libraries. The approach implemented in this approach is very simple.

We have a single global database holder that is used to hold all the information originally stored in the loaded DefaultDatabaseHolder class loaded in the FlowManager.

We implement a FlowManager.initModule method that is used to load the database holder from a shared library. It is assumed the shared library will call this method upon initialization.

When the module holder is loaded, it its contents are added to the global database holder.

This approach, however, does not allow you to unload a module. Since it seems this is really not a concern with DBFlow before, this functionality was not taken into consideration. This also influenced the current design. Also, there should not any name clashes since the key is a class unless the database and tables are in the same package.
Another approach that was not implemented was to have a map of each loaded holder in the global holder. Then implement the necessary methods on the global holder that iterate over the list of maps until it finds what is it looking for. This approach will have the same runtime complexity as the current design, but it will actually not yield the same performance (in theory) for each item stored in the map. This is because the lookup will result in 2 operations, instead of a single operation. This, however, was not evaluated since the current approach was easier to implement.

so far looking good. Can you here show me how this would work with a short code sample here? and maybe paste the gradle file how its getting passed in so I can see if I can write tests for this and usage docs.

it also appears like your code formatting has borked a few of the files, can you clean those up? thanks

and make sure to follow coding style with rest of the project

@agrosner You should create an .editorconfig file that contains your project specific coding style. IntelliJ and Android Studio support it. Please see:

https://www.jetbrains.com/idea/help/configuring-code-style.html#editorconfig
http://editorconfig.org/

@agrosner I actually added the .editorconfig file to the project for you.

@agrosner I added a usage document for database modules to the repo.

@hilljh82 looks great Im going to merge it in, but I prefer not to use String as the parameter, rather I am most likely going to require you specify the generated holder definition .class and it will do the initialization for you. Less room for error I think.


Let species prototypes define valid sexes (Sex Refactor)

About the PR
Still some things to finish

[x] Update UI on species select to only show species options rather than all
[x] Validate sex as part of character validation
[x] Ensure this still works after https://github.com/space-wizards/space-station-14/issues/11519 is resolved, however that happens
[x] Comment / polish pass

Q/A
Q: Should sex be its own component?
I don't really see the utility unless you want sexed animals. Gender should be enough for non humanoids.
Q: What use is this?
Several species really have no reason to be sexually dimorphic, because they are robots, slimes, etc. In the future someone could make a species with 3 sexes, maybe.
Changelog

:cl: Rane

fix: Random names now select based on gender, rather than sex.
fix: Humanoids will no longer default to an inanimate pronoun when their gender is unknown.
tweak: Slimes have no physical sex, only gender.

@vulppine review perhap