(WIP) RFC: Add ORM API

This PR is based on https://github.com/eBay/libovsdb/pull/31
Why add a ORM API?

It makes it much easier to interact with go-ovn as clients do not have to deal with libovsdb specific objects (such as OvsMap and OvsSet.
It automatically enables generic schema-based parsing of any object in any table in any database without needing to write yet another RowTo{X} function.
It can enable considerable reduction of LOC, while having a the same (or even more) functionality
It enables the automatic generation of native bindings so clients can keep track of changes in their databases
It also enables clients to specify what fields they want to read based on their provided models, potentially saving some cycle

How it works?
This work is heavily based on https://github.com/eBay/libovsdb/pull/31 and https://github.com/eBay/libovsdb/pull/30.
We define a simple Model interface
type TableName string
type Model interface {
	Table() TableName
}

Any struct that implements this interface and tags its fields accordingly, can be used to read from / write to a table in the database.
A full DBModel is also a simple struct
// DBModel is a Database model
type DBModel struct {
	types map[TableName]reflect.Type
}

For each table, it has a pointer to it's ORM types
By passing a DBModel to the go-ovn client, it could be able to:

Parse all incoming rows, transform them into instances of the right struct and store them that way in the cache
Pass a pointer to such struct on the callbacks that now can be generic:

type OVNORMSignal interface {
	OnCreated(Model)
	OnDeleted(Model)
}

The client can just cast the incoming Model to the right struct and use it (see example in PR)
Implement a generic Add, Update, Delete functions (no need to add per-table logic any more)

Examples
The best example can be seen here, more specifically in this 70 lines of code: https://github.com/amorenoz/ovnmodel/blob/main/cmd/ovnmon/ovnmon.go
That small program is able to receive native objects for the entire nbctl database without parsing data
Also, a code generator that genereates valid Models and DBModel from a given ovsschema can be seen here
Status
This PR is WIP.
Only reading from the database (i.e: generating events as a result of cache-population) is supported (see examples).
It implements a generic List() command.
My intention is to add Create() Delete() and Update() functions to it but sending it out early on to get feedback

cc @aojea

@amorenoz is this up-to-date? I can't see the Create() and Get() implementations you linked in #145.
I'm also curious on how you plan on handling mutations. A very common use case would be as follows (in pseudo-go)

client := goovn.Client()
// i need to create a logical router static route and reference it from a logical router
// i know the logical router name though

var logicalRouter goovn.LogicalRouter
// I'm not sure what the Get syntax is based on your impl
if err := goovn.Get(logicalRouter, "lr1"); err != nil {
  return err
}

lrsr := &goovn.LogicalRouterStaticRoute{
       // list of fields here etc....
}

if err := goovn.Create(lrsr); err != nil {
   return err
 }

// Now i need to mutate the LR fields `static_routes` column to include my new ID
// taking a guess here at an API, but maybe?
if err := goovn.Mutate(logicalRouter.StaticRoutes, lr.UUID); err != nil {
   return err
}

We're also keen to batch commands in ovn-k8s for performance reasons. I'm not really sure how we'd handle that with this API. Thoughts?

I thought it is somehow agreed between several people of us (@amorenoz @vtolstov, and now @dave-tucker ) but I think it is better to be clear to put my thoughts here: I think about this PR as example only, because we will have code generator to generate this kind of code instead of manually maintaining it.
Moreover, I am not sure if we should even maintain the generated code in this repo. I assume user of libovsdb (and OVN), such as ovn-k8s, can generate code in the client code repo itself (probably multiple schema versions, in different folders), and make the version selection configurable there. So I am not really sure yet what exactly should remain in go-ovn. I think it will be more clear to discuss when we have the code generator working properly.

@amorenoz is this up-to-date? I can't see the Create() and Get() implementations you linked in #145.
I'm also curious on how you plan on handling mutations. A very common use case would be as follows (in pseudo-go)
client := goovn.Client()
// i need to create a logical router static route and reference it from a logical router
// i know the logical router name though

var logicalRouter goovn.LogicalRouter
// I'm not sure what the Get syntax is based on your impl
if err := client.Get(logicalRouter, "lr1"); err != nil {
  return err
}

lrsr := &goovn.LogicalRouterStaticRoute{
       // list of fields here etc....
}

if err := client.Create(lrsr); err != nil {
   return err
 }

// Now i need to mutate the LR fields `static_routes` column to include my new ID
// taking a guess here at an API, but maybe?
if err := client.Mutate(logicalRouter.StaticRoutes, lr.UUID); err != nil {
   return err
}

We're also keen to batch commands in ovn-k8s for performance reasons. I'm not really sure how we'd handle that with this API. Thoughts?

Great point. I didn't think this through yet but it seems that we need "named-uuid" support across API calls. Firstly call the "create" API with a "named-uuid" specified, and then use the same "named-uuid" to call the "update" API to mutate the object that uses the newly created object. Need more details though.

@amorenoz another use case that this API would need to handle is "delete by mutation".
See; https://github.com/eBay/go-ovn/blob/master/logical_router_static_route.go#L156 as an example.
Here to delete the LRSR, we mutate the static_routes field to the LR remove the UUID from it's list and due the entry from the static routes table is automagically cleaned up. IIRC a delete will fail on an object that's referenced in another table.
This might require some parent/child modelling in order for this to work as expected.

So I am not really sure yet what exactly should remain in go-ovn. I think it will be more clear to discuss when we have the code generator working properly.

Agreed we'll know more once we have a working generator,
There is still an amount of boilerplate that would be needed...
Setting up OVSDB connection, Setting up the Monitor and the cache population...
The Get method (which is very useful indeed) relies on accessing the cache.
If all of these could be moved in to libovsdb then I'd be happy.

@amorenoz another use case that this API would need to handle is "delete by mutation".
See; https://github.com/eBay/go-ovn/blob/master/logical_router_static_route.go#L156 as an example.
Here to delete the LRSR, we mutate the static_routes field to the LR remove the UUID from it's list and the entry from the static routes table is automagically cleaned up. IIRC a delete will fail on an object that's referenced in another table.
This might require some parent/child modelling in order for this to work as expected.

Would this work by making two API calls and executing the returned commands together in a single transaction?

@dave-tucker
I intended to leave the entire CRUD API for a later PR but, let's just put everything on the table so we can discuss clearly.
With the latest update,

@amorenoz is this up-to-date? I can't see the Create() and Get() implementations you linked in #145.
I'm also curious on how you plan on handling mutations. A very common use case would be as follows (in pseudo-go)

Please see https://github.com/eBay/go-ovn/pull/136/files#diff-bde7e540ec82692bc60144ad5ce7df3dc960fe297f090b9d8379391a0def5166

@amorenoz another use case that this API would need to handle is "delete by mutation".

Also, see https://github.com/eBay/go-ovn/pull/136/files#diff-bde7e540ec82692bc60144ad5ce7df3dc960fe297f090b9d8379391a0def5166 for an example of delete by mutation

I thought it is somehow agreed between several people of us (@amorenoz @vtolstov, and now @dave-tucker ) but I think it is better to be clear to put my thoughts here: I think about this PR as example only, because we will have code generator to generate this kind of code instead of manually maintaining it.
Moreover, I am not sure if we should even maintain the generated code in this repo. I assume user of libovsdb (and OVN), such as ovn-k8s, can generate code in the client code repo itself (probably multiple schema versions, in different folders), and make the version selection configurable there. So I am not really sure yet what exactly should remain in go-ovn. I think it will be more clear to discuss when we have the code generator working properly.

@hzhou8 , maybe I misunderstood our previous discussion, but my approach here is not to automatically generate the entire client code but just the Database Model and keep the library generic enough. With the current state of this PR, the client can use the code generator in cmd/modelgen (still very raw) to generate files such as:
// Code generated by "ovsmodel"; DO NOT EDIT.

package modelgen

import (
	goovn "github.com/ebay/go-ovn"
)

var (
	ACLTable goovn.TableName = "ACL"
)

//ACL struct defines an object in ACL table
type ACL struct {
	UUID        string            `ovs:"_uuid"`
	Direction   string            `ovs:"direction"`
	Log         bool              `ovs:"log"`
	Meter       []string          `ovs:"meter"`
	Priority    int               `ovs:"priority"`
	Severity    []string          `ovs:"severity"`
	Action      string            `ovs:"action"`
	ExternalIds map[string]string `ovs:"external_ids"`
	Match       string            `ovs:"match"`
	Name        []string          `ovs:"name"`
}

// Table returns the table name. It's part of the Model interface
func (*ACL) Table() goovn.TableName {
	return ACLTable
}

As you can see, it's a very simple type definition that just makes live slightly easier for clients but does not implement any logic. Clients can still:

Create their own types and use them (maybe defining less fields if not interested in all of them)
Use their old types (auto-generated or not) with newer versions of go-ovn: simple bug fixing for go-ovn and simple upgrading for clients
Use the old API, i.e: no need to do any kind of code-generation for ovnimp to be able to compile and use go-ovn

What do you think?
If the preferred way is to auto-generate the client code, I'd take a look at @dave-tucker 's approach at #145

@dave-tucker

If all of these could be moved in to libovsdb then I'd be happy.

+1 for moving the cache down to libovsdb

Please see https://github.com/eBay/go-ovn/pull/136/files#diff-bde7e540ec82692bc60144ad5ce7df3dc960fe297f090b9d8379391a0def5166

@amorenoz Thanks for the update... and you're using OVNCommands too which allows for us to batch things in to one transaction. Nice!
UpdateFields(Model, []string, ...string) (*OvnCommand, error)

An issue here is that you are using the update operation vs. the mutate operation.
This will replace the contents of the field with whatever we provide.
This is an important difference, because the copy of the object we're updating may be stale when the command is executed... which would cause us to overwrite the data in that field.
I wonder whether it might be better to have:
Mutate(from Model, to Model) (*OvnCommand, error)

This would compare two models and generate a mutate operation for each field that is different

Please see https://github.com/eBay/go-ovn/pull/136/files#diff-bde7e540ec82692bc60144ad5ce7df3dc960fe297f090b9d8379391a0def5166

@amorenoz Thanks for the update... and you're using OVNCommands too which allows for us to batch things in to one transaction. Nice!
UpdateFields(Model, []string, ...string) (*OvnCommand, error)

An issue here is that you are using the update operation vs. the mutate operation.
This will replace the contents of the field with whatever we provide.
This is an important difference, because the copy of the object we're updating may be stale when the command is executed... which would cause us to overwrite the data in that field.
I wonder whether it might be better to have:
Mutate(from Model, to Model) (*OvnCommand, error)

This would compare two models and generate a mutate operation for each field that is different

Yep, that's a good idea. Definitely doable and very useful. The user will then be able to choose if a full update is required or only a mutation is needed.

If the preferred way is to auto-generate the client code, I'd take a look at @dave-tucker 's approach at #145

@amorenoz Yes I still think it is better to generate all the code that can be deduced from schema. Otherwise, it is hard to manage the schema changes in go-ovn while keeping backward comparability. For cache implementation, since it is generic to ovsdb clients, I'd also move it to libovsdb, and with your native binding support it is now easier, right?

The plan is to add this API to libovsdb directly: https://github.com/ovn-org/libovsdb/pull/78
Closing this one


Separate the project into two libraries - one for tika part, and one for sending JSONs to elastic

Required by: https://github.com/ivan-cukic/litef-conductor/issues/2

The jar is now separated in two projects, tika-extensions and elastic-indexer.


fix: deprecating creating own instances

Complete each step to get your pull request merged in. Learn more about the workflow this project uses.

[ ] Assign members of your team to review the pull request.
[ ] Wait for pull request status checks to complete. If there are problems, fix them until you see that all status checks are passing.
[ ] Wait until the pull request has been reviewed and approved by a teammate
[ ] After pull request is approved, and you determine it's ready add the label "Ready to merge" to the pull request. A bot will squash and merge the pull request for you after the label is added.

:tada: This PR is included in version 1.2.0-beta.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


update german translation

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.972%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
3566

Relevant Lines:
3567

💛  - Coveralls

Perfect. thanks a lot for the quick update!


fs_write failed

Discussed in https://github.com/zephyrproject-rtos/zephyr/discussions/70163

Originally posted by AydinyanNarek March 13, 2024
Hello,
Introdcution
I am using STM32 microcontroller and Zephyr 3.6.0.
My application logger logs data to the Ram-FS, instead of flash memory. (Flash memory has a fixed count of write operations).
I have created Ram-FS(/etc and /tmp) using FALSH_SIMULATOR.
It looks like this.
/ {
	soc {
		flash_controller0: flash-controller@0 {
			compatible = "zephyr,sim-flash";
			reg = <0x00000000 DT_SIZE_K(64)>;

			#address-cells = <1>;
			#size-cells = <1>;
			erase-value = <0xff>;

			flash_sim0: flash_sim@0 {
				status = "okay";
				compatible = "soc-nv-flash";
				erase-block-size = <512>;
				write-block-size = <1>;
				reg = <0x00000000 DT_SIZE_K(64)>;

				partitions {
					compatible = "fixed-partitions";
					#address-cells = <1>;
					#size-cells = <1>;

					lfsram_partition0: partition@0 {
						label = "/tmp";
						reg = <0x00000000 0x00008000>;
					};

					lfsram_partition1: partition@1 {
						label = "/etc";
						reg = <0x00008000 0x00010000>;
					};
				};
			};
		};
	};
};

    fstab {
        compatible = "zephyr,fstab";
        lfs1: lfs1 {
			compatible = "zephyr,fstab,littlefs";
			read-size = <512>;
			prog-size = <512>;
			cache-size = <4096>;
			lookahead-size = <512>;
			block-cycles = <512>;
            partition = <&storage_partition>;
			mount-point = "/opt";
			automount;
        };

          lfsram0: lfsram0 {
	          compatible = "zephyr,fstab,littlefs";
	          mount-point = "/tmp";
	          partition = <&lfsram_partition0>;
	          automount;
	          read-size = <16>;
	          prog-size = <16>;
	          cache-size = <64>;
	          lookahead-size = <32>;
	          block-cycles = <512>;
          };

          lfsram1: lfsram1 {
	          compatible = "zephyr,fstab,littlefs";
	          mount-point = "/etc";
	          partition = <&lfsram_partition1>;
	          automount;
	          read-size = <16>;
	          prog-size = <16>;
	          cache-size = <64>;
	          lookahead-size = <32>;
	          block-cycles = <512>;
          };
    };

Notes.

/opt is using flash0 memory. (just skip this)
The combined log size is less than 10kb, which is less then the /tmp partition size
I am not writing 10kb log at once. I am doing small logs (max 512 bytes at a time).

Problems.
I am writing logs to /tmp directory using std::ofstream

The file remains empty Until I call a close function on the stream. (std::endl, std::flash, rdbuff(0,0,) ..etc doesn't help)
Using the open\close combination after each write helps the data to appear in the file, however when I am doing it multiple times(let's say more than 50)  the fs_write returns error code -22 which is INVALID ARGUMENT ERROR and printing errno returns The Socket is not available.

Does someone have an idea about this ?

@AydinyanNarek your second partition is to large to fit in the specified 64kB of the simulator, reduce the size of the second partition or increase the simulator size.

@Laczen what do you mean saying  second partition ?

@Laczen what do you mean saying second partition ?

lfsram_partition1 starts at 32kB and is 64kB, so this needs 96kB.

@Laczen what do you mean saying second partition ?

lfsram_partition1 starts at 32kB and is 64kB, so this needs 96kB.

Thanks, it works now.
Should I open an issue related to std::flush related functional?
The problem is that  std::ostream internal buffer's(rdbuf) data will not be written to the file without closing the file.


Adding a connection doesn't appear to work

Operating System: Windows 10
LightTable version: 0.8.1

I'm a complete LightTable beginner so I maybe doing something wrong. But the plugin doesn't appear to be creating a connection. I managed to get a simple error dialog up once, just saying 'Couldn't create a connection', so I restarted LT. After a restart I can neither generate an error or eval any syntax.

I have installed the plugin
I have reloaded behaviors
I have PHP in my path (it is very old though v5.2.13), i.e. php -i at the command line works
I add a connection and specifiy %HOMEPATH%\lighttable i.e. C:\Users\Ian\lighttable
If I try to select some syntax in my php file (which is in my project directory) and hit Ctrl+Shift+Enter nothing happens
If I check the connections again there is no PHP connection there.
If I open the console - no errors are displayed.

Sorry @ianchanning for not having replied earlier.
Have you figured a way how to use the plugin?
Have you found an alternative solution in between?

Hi @thierrymarianne, no sorry, I never did and I've stopped using PHP now.


Replace endian specific copy functions with DataView

Refs: https://github.com/guybedford/cjs-module-lexer/pull/13#discussion_r504212110
@guybedford This is the tidied up version of the hack I did to get the tests passing on AIX (big endian). I'm okay with https://github.com/guybedford/cjs-module-lexer/pull/13 so am not fussed if this lands or is just closed out, but I've opened it anyway as an FYI.
FWIW the original hack kept the copyBE and copyLE functions and only used DataView for copyBE. It was hacky because it took me a while to realise that the source length was in characters and DataView's length/offsets were in bytes.

Closing as the other approach is now working well. Thanks again for the help on this one @richardlau.


Support For multipart messages through XPUB/XSUB

This relates to #275. When trying to send multipart messages and XPUB/XSUB proxy, the proxy is forwarding message part where the binding is expecting an integer, and crashes.
problem can be reproduced with this snippet
TypeError: Second argument should be an integer
    at Socket._flush (/home/esatterwhite/dev/js/zmq-275/node_modules/zmq/lib/index.js:524:19)
    at Socket.send (/home/esatterwhite/dev/js/zmq-275/node_modules/zmq/lib/index.js:463:14)
    at emit (events.js:106:17)
    at Socket._flush (/home/esatterwhite/dev/js/zmq-275/node_modules/zmq/lib/index.js:510:19)
    at _zmq.onReady (/home/esatterwhite/dev/js/zmq-275/node_modules/zmq/lib/index.js:193:12)
pub sub: there was an un expected error: Second argument should be an integer

Your problem seems to be that zmq.ZMQ_SNDMORE is undefined. It's exposed on the native binding, but not on the Node module.

So what is it, if not an integer? zmq.ZMQ_SNDMORE should already be an integer.
> var zmq = require('./');
undefined
> zmq.ZMQ_SNDMORE
2

ZMQ_SNDMORE is 2

That isn't the problem. I've said it 3 times, The XPUB socket is trying to forward the additional parts of the message to _zmq.send
If I add a console.log to line 524, just before the actual send
 console.log(this.type, args[0].toString(), args[1].toString() );

it outputs this
xpub test monay
``

why are you setting sockopt limits for xpub and xsub? Just curious

so the proxy doesn't drop messages

oh i've never had to set that it's never dropped messages for me

either way i'll start looking into this issue today

On a side note: If I remember correctly, the high water mark options don't do anything in this implementation, due to that polling loop that does the multiplexing. zeromq.node never blocks, even if the zmq specs say it should.

This was also somewhat of a duplicate of  #274 which I opened a while back

@esatterwhite, would you pls run:
$ pkg-config --modversion libzmq

and let me know what prints

3.2.4

zmq 4.0 added support for multipart messages via the xpub / xsub socket types.

you said this in https://github.com/JustinTulloss/zeromq.node/issues/274 and I agree.
I think without 4+ you'll have trouble with multipart message support.

I was using 4.0 on my work computer where I found the problem. It's the same behavior, it was sending the second part of the message to _zmq.send rather than the flag.
I'll update this computer to 4+ and see if that corrects it, but It  looks like their is a bug in zeromq.node either way.

fair enough.
keep the issue open, l'll dig further into this

confirmed, same problem with 4.0.5

looks like you're dropping messages in the xsub's onmessage callback.
I forked your gist and made the following adjustment to illustrate exactly where the message loss is:
https://gist.github.com/reqshark/38bb0d1c301025374d98#file-proxy-js-L42-L47
are we good to close this?

ah, ok. its not dropping messages. the messages are delivered in a single event rather than being forwarded as they are sent during the xpub <>xsub forwarding.
So am I reading the code right? zeromq.node is consolidating the message parts and sending them all at the end?
If I change the proxy to do xpub.send.call( xpub, arguments ) that works, but It seems like a bit of a work around. It looks like the xpub socket should deal with upstream multi parts in libzmq
I'm just trying to understand where the problem is. it seems like in the case of multipart messages through xpub/xsub, that the parts have to be consolidated, exploded one too many times...

I'm just trying to understand where the problem is.

I dont think there is a problem. if anything your use case is a good argument to enhance our JS proxy method, assuming the native zmq_proxy() operation does the same.
@ronkorving, @kkoopa what do you guys think?

I don't really know. How does, say, pyzmq handle this? Is there anything written about this in the zmq specification?

Ya I think we definitely want to return there, I agree 100%.
I'll revert/PR to fix that later today
Sent from my iPhone

On Apr 2, 2015, at 12:42 PM, Benjamin Byholm<EMAIL_ADDRESS>wrote:
I don't really know. How does, say, pyzmq handle this? Is there anything written about this in the zmq specification?
—
Reply to this email directly or view it on GitHub.

Oops nvm wrong thread

I honestly have never used these features, so have no real thoughts on this. Sorry I can't be of more help.

zmq.node and pyzmq do pretty much the same thing with multi-part messages. They collect all of the parts internally into an array before handing it off to the consumer. However, pyzmq's implementation was put in place before xpub/xsub, and both were implemented before there was multi-part message support for the socket types.
The primary use case for the xpub/xsub pairing is a dumb proxy. I don't think that it makes sense for the xsub socket to collect all of the parts before firing the message event, Instead it seems more intuitive for the message parts to be sent as they come, as it looks like xpub and xsub sockets in libzmq take care of consolidating the parts internally.
The zmq spec doesn't say much about how these types should handle multi-part messages, and the fact that the functionality for it didn't land until 4.0, it probably wasn't really thought out. There aren't any examples of it in the zquide either.
perhaps,  at the least, could there be an option in zeromq.node to forward message parts on the xsub type as the come?

That sounds reasonable. PRs welcome.

I believe the problem is the message event spreads the multipart message into multiple arguments, whereas send expects an array for multipart messages. I solved it by doing the following:
xsub.on('message', function() {
  xpub.send(Array.prototype.slice.call(arguments));
});


Expand DBBooleanIntegrationTest

The current org.vitrivr.cineast.core.db.DBBooleanIntegrationTest only tests a subset of possible invocations of the DBSelector class. Possible extensions include:

Testing the getRowsAND method with different conditions
More tests for the different RelationalOperator values

Note: Currently only available on the new-cottontail-api branch, see #182

Is DBBooleanIntegrationTest a Java file? it seems to do not exist in current project.

Is DBBooleanIntegrationTest a Java file? it seems to do not exist in current project.

Currently only available on the new-cottontail-api branch, i've updated the issue


feature/insights-contact-merge

Updates to Contact Merge functionality are done to display two buttons on the Contact Merge page. First button 'Search By Contacts' will redirect to the existing contact merge functionality. The second button 'Show Duplicate Record Sets' will redirect to list of DRSs related to contact duplicate rules. This second page includes pagination to handle large number of DRS records. The 'Duplicate Record Set Name', 'Duplicate Rule' and 'First Contact Name' columns of the DRS list contains the links to the detail page of the respective records

@espl-ishita Would you mind renaming this branch to feature/insights-contact-merge? The feature part is critical in the branch name. It ensures that the branch remains in sync with master. Our CI processes will automatically sync master into all branches that being with feature/. Without that, branches quickly become out of date. Plus, if I'm not mistaken, our automatic build system will not execute properly unless the branch name starts with feature.

Closing this pull request as created a new pull request for feature/insights-contact-merge branch


VSCode TailwindCSS Addons Require tailwind.config.js to work

Thanks @brandonpittman for building the plugin.
Kindly add a note in the documentation that the VSCode addons:

TailwindCSS Intellisense
Headwind

...require tailwind.config.js within the project folder to be present in order for them to work. After generating the config file using the command ./node_modules/.bin/tailwind init to generate the file, VSCode needs to be restarted in order for the plugins to function.

@brandiqa vim 4 life.


Usage in filters ?

Hello,
Love this plugin! I managed to get this working as a filter as well, only closing an indicator does not feed back to the selected values.
So if I close the active filter (by clicking the X), the values are still displayed in the categories field.

(They are correctly linked, active filters showing the ID instead of the name.)
I tried several thing, but did not manage to get it to work. Any thoughts on this?

That's great to hear you're enjoying the plugin! I never thought about using it as a filter before; that's a clever idea.
Since you've mentioned having to use some workaround to make it function, I'm considering creating a TreeSelectFilter class that can handle everything seamlessly.
I'll keep you in the loop and update this issue as I make progress.

Hey, sorry for the wait! I think I've got a solution for your problem. It involves making some queries to the database when using filters, but I don't think it'll be a big performance problem. Here's a quick snippet of what I came up with. I'll be adding this to the documentation.
->filters([
    Filter::make('tree')
        ->form([
            SelectTree::make('categories')
                ->relationship('categories', 'name', 'parent_id')
                ->independent(false)
                ->enableBranchNode(),
        ])
        ->query(function (Builder $query, array $data) {
            return $query->when($data['categories'], function ($query, $categories) {
                return $query->whereHas('categories', fn($query) => $query->whereIn('id', $categories));
            });
        })
        ->indicateUsing(function (array $data): ?string {
            if (! $data['categories']) {
                return null;
            }

            return __('Categories') . ': ' . implode(', ', Category::whereIn('id', $data['categories'])->get()->pluck('name')->toArray());
        })
])

Let me know if this solved your problem. @ThisIsMyFavouriteJar

Hi Dennis, Thank you for this update, looks good!


LANZ 2689 eestructure settings into json file

refactor: LANZ-2689 reestructure settings into json file

PR for triggering gh actions


connectionDidConnect is not called (iOS)

After i accept the connection the connection's delegate methods are not called.

I am not an iOS developer and please correct me if i am wrong.
To make these delegate methods to be called i had to add self.connection.delegate = self where we set the connection and it seems that is working now.
-(void)device:(TCDevice *)device didReceiveIncomingConnection:(TCConnection *)connection {
    self.connection = connection;
    self.connection.delegate = self;
    [self javascriptCallback:@"onincoming"];
}


How to blit the contents out of a SurfaceTexture?

It would be nice if there was a way to blit the contents of a SurfaceTexture to a GL Texture or surfman Surface that worked reliably on all platforms. My attempts to do this (https://github.com/asajeffrey/tmp/blob/e0182496afa8a96e67a30ce41cda72ed9199fbc4/main.rs) don't work on x11 (GL error 0x506).

IRC chat at https://mozilla.logbot.info/servo/20191120#c16772801

Also https://mozilla.logbot.info/servo/20191121#c16774069

More IRC: https://mozilla.logbot.info/servo/20191121#c16776799 and https://mozilla.logbot.info/servo/20191122#c16778300 so it looks like this should be fixed in surfman v0.2.

There is now a test for this in 0.2.


LookupError

================================= short test summary info ===================================
FAILED test_WordFrequency.py::test_get_frequency - LookupError

Glad you found an error. Fix the bug by creating a new branch and pull request. A good way to build your skills through debugging


Update to stable CodeMirror 6?

Depending on the old 0.19 versions (and removed libraries like @codemirror/highlight) makes it really hard to use this library in a project using stable CM6 now that it's been released.
https://marijnhaverbeke.nl/blog/codemirror-6.html

@ErikSchierboom I assume if I update this and push a new release that won't harm Exercism because we're (maybe?) pinned to the existing NPM release, or is that a faulty assumption because we're not 1.0 yet?
Actually if we're major pinned and I bump it all the way to 1.0 with the next release, that would be good, yes?   Then Exercism could catch up when ready?
Let me know if I'm mistaken here.

makes it really hard to use this library in a project using stable CM6 now that it's been released.

For sure, do you know what happened to highlight?  Did it just get absorbed?  I haven't been following CodeMirror - I only built this because it was necessary for full Wren support on Exercism.

The deprecated notice says:

As of 0.20.0, this package has been split between @lezer/highlight and @codemirror/language

https://www.npmjs.com/package/@codemirror/highlight

Thanks!  I'll look into this after we hear back from Erik.  Could you possibly share what project you're using this in?  Pretty awesome to see it being used outside of the Exercism ecosystem.

Sure, code.golf gained support for Wren today with https://github.com/code-golf/code-golf/commit/f7c0d8a77e637e049e7245a676057e246223f0a0 but no syntax highlighting yet. The frontend is all CM6.

I wonder if there is some best practice on what versions we should pin against to be most useful:
    "@codemirror/autocomplete": "^6.2.0",
    "@codemirror/language": "^6.2.1",
    "codemirror": "^6.0.1",

Is that going to disallow people using 6.0.0?

Assuming these changes also work with 6.0.0 (I haven't tested. Then I think ^6 would offer the best compatibility with end users:

https://semver.npmjs.com

Assuming these changes also work with 6.0.0

I the API is stable I'd assume it should.

After review I'll merge and ship 1.0.0.

re Exercism: we really were at a beta version before. Bumping it should be okay, because if you bump it, it won't stop Exercism from building as they will need to udpate their log file. If this code language pack works with both the older version and the newer version, there are different ways to accomplish this instead.
re version range:
It really depends what you're trying to accomplish.
So for both things, it comes down to the following: this is a language pack. It makes no sense to install this without depending on code mirror. That means that the version requirement is just that: indicatory of what it expects and supports. In this particular case I highly recommend removing any code mirror dependency and instead add those as peer dependencies. This will lead to deduplication no matter what tool the consumer is using and it leads to a warning instead of a double packaged version or error if the version doesn't match.
If you intend to release or recheck this library regularly you could pick ^6.0.0 / 6.x. If you don't care at all but it may break in the future you can do * which means "be installed, don't care which version".
6.x is the same as ^6.0.0 and 6. ^6 is also the same, but not a syntax i recommend.
~ is meant for patch, ^ mean for minor. Setting a lowest x and y that you support is generally not bad.

https://github.com/exercism/codemirror-lang-wren/blob/77cbbbc67ae6aedbbb44c63bf64ce91d71cb33d0/package.json#L30
It sounds like you're suggesting I make all 4 (all of the actual non-dev dependencies) peer, am I understanding correctly?

If you intend to release or recheck this library regularly you could pick ^6.0.0 / 6.x.

Wait, "if I intend to check regularly"... isn't pinning ^6.0.0 I can check less regular option?  I'm assuming this is reliable semver, so if it works now it shouldn't break until 7.  If that's the case and there are no bugs here I'd prefer to not need to touch this again until CodeMirror 7. :-)

@ErikSchierboom I assume if I update this and push a new release that won't harm Exercism because we're (maybe?) pinned to the existing NPM release, or is that a faulty assumption because we're not 1.0 yet?

Currently, we're not even pinning to NPM but tp the repo:

"@exercism/codemirror-lang-wren": "https://github.com/exercism/codemirror-lang-wren",

See https://github.com/exercism/website/blob/main/package.json#L18
Let me know what you'd like me to pin it to, and then I can update.


HMap.apply can not be used out of the box

The following program:
object Main extends App {
  import shapeless._

  trait  Key { type Value }
  object Key {
    type Aux[V] = Key { type Value = V }
    def apply[V]: Key.Aux[V] = new Key { type Value = V }
  }

  val name = Key[String]
  val id   = Key[Int   ]

  val map = HMap[(Key.Aux ~?> Id)#λ](
    name -> "John Smith"
  , id   -> 123
  )

  println(map(name))
}

Fails with:
could not find implicit value for parameter cse: shapeless.poly.Case[shapelesshmap.Main.map.type,shapeless.::[shapelesshmap.Main.Key.Aux[String],shapeless.HNil]]
[error]   println(map(name))

This is so, because apply is inherited from Poly1, and it requires an implicit Case instance in scope. HMap class has this instance, but it is not picked up because the map is stored in val.
Normally, we declare Poly as singleton objects, otherwise their Case instances are also not picked up. However, I do not see a type safe way to create an HMap as a singleton object.
The following code works:
object Main extends App {
  import shapeless._

  trait  Key { type Value }
  object Key {
    type Aux[V] = Key { type Value = V }
    def apply[V]: Key.Aux[V] = new Key { type Value = V }
  }

  val name = Key[String]
  val id   = Key[Int   ]

  val map = HMap[(Key.Aux ~?> Id)#λ](
    name -> "John Smith"
  , id   -> 123
  )
  import map.caseRel

  println(map(name))
}

I agree that the ergonomics aren't perfect here, however you can get close to what you want be defining map as an object,
object map extends HMap[(Key.Aux ~?> Id)#λ](Map(name -> "John Smith", id   -> 123))

scala> map(id)
res0: Int = 123

scala> map(name)
res1: String = John Smith

The reason that this works without an import is that the definition of map as an object create an implicit scope with is automatically searched for instances.

The problem with this solution is that it is not type safe:
  object map extends HMap[(Key.Aux ~?> Id)#λ](Map(name -> 10, id   -> 123))

Compiles perfectly. Further:
val x: Option[String] = map.get(name)

Also works, both on compile and runtime, I think because the type of Option is erased.
Another problem is this:
  object map extends HMap[(Key.Aux ~?> Id)#λ](Map(name -> 10, id   -> 123))
  val m2 = map + (name -> "Foo")

  println(m2(name))

This also fails because implicit Case can not be found. + creates a new map, for which implicits are not available.
I believe this can also be an obstacle for writing combinators for Poly, like andThen or map.

Agreed. For the object approach to work we would need an HMap constructor which worked similarly to HMap's companion object apply. Would you like to take a swing at that?

Indeed, this can be a solution. I didn't know it is allowed to have implicit parameters in the constructor, but this worked:
  class Foo(a: Int)(implicit b: String) {
    def f() = println(b)
  }

  implicit val b: String = "foo"

  object foo extends Foo(10)
  foo.f()

However, this will not solve the + problem, since the object created in a method looses its implicit scope when used outside that method.
I think the problem here is that HMap is not an ADT. In fact, I think Poly itself can well be an ADT.
If Poly = Function[HList, _] | AlternativePoly[Poly, Poly], then it is easy to represent both HMap and Poly uniformly. In the current implementation, the Poly is essentially an alternative of ordinary functions.
HMap can be expressed as a set of Poly under alternative, each one defined on a single key type: Alternative[Function[A, B], Tail]. When adding another key-value pair to M <: HMap, the result is Alternative[Function[K, V], M].
The advantage is that we can get rid of the dependency on the self type of the created Polys and HMaps, and hence have combinators on them without related problems. The combinators themselves can be the operations in question reified (AndThen[Poly, Poly], FlatMap[Poly, Poly] etc), like it is done for HLists.
Though if the underlying Scala Map is removed, the advantage of efficient implementation of that Map access operations will also be removed.
An implementation for Case resolution under that ADT can be an ordinary tree traversal till first match:
  implicit def case: Case[Function[A, B], A, B] = ???
  implicit def caseAlt: Case[Alternative[F, G], A, B] = implicitly[Case[F, A, B]] or implicitly[Case[G, A, B]]
  implicit def caseAndThen: Case[AndThen[F, G], A, B]] = implicitly[Case[F, A, T]] and implicitly[Case[G, T, B]] forSome T

What do you think?

I'm very keen to see people explore alternative ... give it a try and see where it leads :-)

Here's a runnable sketch of alternative-based Poly implementation and Poly-based HMap implementation I came up with:
package shapelesshmap

// Tests
object Main extends App {
  // Poly tests
  val f = SimplePoly { x: Int     => x * x }
  val g = SimplePoly { x: String  => x * 2 }
  val m = SimplePoly { x: Double  => x / 2 }
  val k = SimplePoly { x: Boolean => !x    }
  val h = Or(Or(f, k), Or(g, m))

  println(h(2))      // 4
  println(h("Foo"))  // FooFoo
  println(h(2.2))    // 1.1
  println(h(true))   // false

  // HMap tests
  class Rel[K, V]
  trait Key { type Value }
  object Key {
    type Aux[V] = Key { type Value = V }
    implicit def rel[T, K <: Key.Aux[T]]: Rel[K, T] = new Rel[K, T]
  }

  object name extends Key { type Value = String }
  object id   extends Key { type Value = Int    }

  val map = new HMap[Rel, EmptyPoly.type](EmptyPoly)
  val newMap = map + (name, "John Smith") + (id, 10)

  println(newMap(name))  // John Smith
  println(newMap(id))    // 10
}

// Poly base
trait Poly

object Poly {
  implicit def polyOps[P <: Poly](p: P): PolyOps[P] = new PolyOps(p)
}

class PolyOps[P <: Poly](p: P) {
  def apply[A, B](a: A)(implicit e: Executor.Aux[P, A, B]): B = e(p, a)
}

// Executor for Poly
trait Executor[P <: Poly, A] {
  type Out
  def apply(p: P, a: A): Out
}

object Executor { type Aux[P <: Poly, A, Out0] = Executor[P, A] { type Out = Out0 } }

// Simple poly
case class SimplePoly[A, B](work: A => B) extends Poly

object SimplePoly {
  implicit def simpleExec[A, B]: Executor.Aux[SimplePoly[A, B], A, B] = new Executor[SimplePoly[A, B], A] {
    type Out = B
    def apply(p: SimplePoly[A, B], a: A): Out = p.work(a)
  }
}

// Or poly
case class Or[F <: Poly, G <: Poly](f: F, g: G) extends Poly

object Or {
  implicit def f[F <: Poly, G <: Poly, A, B](implicit e: Executor.Aux[F, A, B]): Executor.Aux[Or[F, G], A, B] = new Executor[Or[F, G], A] {
    type Out = B
    def apply(f: Or[F, G], a: A): B = e.apply(f.f, a)
  }

  implicit def g[F <: Poly, G <: Poly, A, B](implicit e: Executor.Aux[G, A, B]): Executor.Aux[Or[F, G], A, B] = new Executor[Or[F, G], A] {
    type Out = B
    def apply(f: Or[F, G], a: A): B = e.apply(f.g, a)
  }
}

// Empty poly
case object EmptyPoly extends Poly

// HMap
class HMap[R[_, _], U <: Poly](val underlying: U) extends Poly {
  def +[K <: AnyRef, V](k: K, v: V)(implicit e: R[K, V]): HMap[R, Or[SimplePoly[k.type, V], U]] =
    new HMap(Or(SimplePoly[k.type, V] { _: k.type => v}, underlying))
}

object HMap {
  implicit def e[R[_, _], U <: Poly, A, B](implicit ue: Executor.Aux[U, A, B]): Executor.Aux[HMap[R, U], A, B] = new Executor[HMap[R, U], A] {
    type Out = B
    def apply(m: HMap[R, U], a: A): B = ue(m.underlying, a)
  }
}

Do you think you could extend it to polymorphic cases?

What polymorphic cases do you mean?

If you meant natural transformations, the following works:
// Natural transformations
trait ~>[F[_], G[_]] extends Poly {
  def f[T](x: F[T]): G[T]
}

object ~> {
  implicit def e[F[_], G[_], T]: Executor.Aux[~>[F, G], F[T], G[T]] = new Executor[~>[F, G], F[T]] {
    type Out = G[T]
    def apply(f: ~>[F, G], a: F[T]): G[T] = f.f(a)
  }
}

val natural = new ~>[List, Option] {
  def f[T](a: List[T]): Option[T] = a.headOption
}

println(natural(List(1)))
println(natural(List("Foo")))

I meant something like your example built with Or where one of the branches is polymorphic.

It already supports that out of the box, since the arguments to Or are Poly and ~> extends Poly:
  val natural = new ~>[List, Option] {
    def f[T](a: List[T]): Option[T] = a.headOption
  }
  val f = SimplePoly { x: Int => x * x }
  val polyOr = Or(f, natural)

  println(polyOr(2))    // 4
  println(polyOr(List(2)))  // Some(2)
  println(polyOr(List("Foo")))  // Some(Foo)


Applied Visual Design: Modify Fill Mode of an Animation - Not accepting all valid answers

Challenge Name
Applied Visual Design: Modify Fill Mode of an Animation
Issue Description
If you insert the "animation-fill-mode: forwards;" between "animation-name: background-color;" and "animation-duration: 500ms;" or above "animation-name: background-color;", the behavior is exactly what is expected of the challenge, however the test fails stating:
message: button:hover should have a animation-fill-mode property with a value of forwards.
Inserting the line at the end of both statements allows you to pass the test.
Browser Information

Browser Name, Version: Opera (identified as Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 OPR/50.0.2762.58), Version 50.0
Operating System: Windows 10 64-bit (WoW64)
Mobile, Desktop, or Tablet: Desktop

Your Code

Screenshot

@raisedadead done.


Implement lemmas 1 & 2 from #1765

Add assertWithMsg

Use Except for anachronisticProtocolLedgerView
To be consistent with the other ledger methods, e.g., applyLedgerBlock.

Check Lemma 1 from #1765

Check Lemma 2 from #1765

Switch the order of validation in applyExtLedgerState
Fixes #1771.

Lemma 3 is harder to check, because of https://github.com/input-output-hk/ouroboros-network/issues/1765#issuecomment-597006390, but also because we suddenly have ApplyTx blk and HasTxs blk constraints on applyExtLedger, which are rather annoying. Adding them as superclasses LedgerSupportsProtocol is convenient, but annoying in ouroboros-consensus-byron, because the instances are defined in separate modules. Moreover, DualByronBlock doesn't support HasTxs, so that's a no go :slightly_frowning_face:.

bors r+


Implement and test GHCJS.Buffer.{to,from}ByteString

Also exposes create and fixes a bug in byteLength.
I've pretty well convinced myself that the use of unsafePerformIO in
toByteString is safe if no one is playing mutate-the-immutable-Buffer
games.  I'm rather more unsatisfied with the unsafeForeignPtrToPtr ion
fromByteString.

Thanks for implementing this, and adding tests, greatly appreciated!
I think you can avoid the unsafePerformIO by importing GHC.ForeignPtr and constructing the ForeignPtrContents by hand (with the PlainPtr constructor, the MutableByteArray# inside is just the same JS buffer object). That should make the code a bit more optimizable.


[Inventory] Logic to Test VPD Inventory xyz

Currently 'Get VPD Inventory List" is derived from models example data/Barreleye.py
The URI is still /org/openbmc/ in the model files.. however we won't be changing there the URI path but needs to be prepared from the YAML or other mechanism to check the presence properties.

The patches for inventory are ready... it will get merge sooner this sprint..
To ready for this changed,, I have coded the FRU data generation using YAML parser using
https://github.com/openbmc/openbmc-test-automation/issues/330
The code is under review.. and for this task I' ll start writing the code..

Changing the estimate since the YAML logic is addressed in different commits.

The following are needed in order

[ ] YAML changes
[ ] Base utility changes for fetching, listing the FRU's
[ ] Test code to Test the FRU's fields

We will need the FRU field to identify if its a FRU or not
https://github.com/openbmc/openbmc/issues/1098

As per Patrick, There is going to be a change to make the inventory paths all lower-case.
/xyz/openbmc_project/inventory and not /xyz/openbmc_project/Inventory

This has other dependencies on the inventory and the YAML code which is in review..


Add support for polars v0.14.0

Addresses the changes made in pola-rs/polars#4256 with some hacky solutions.
TODO:

[ ] Fix LazyFrame.fetch() and similar methods.

Codecov Report

Merging #23 (c4502ed) into main (9ff2bc0) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #23   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            6         6
  Lines          460       491   +31
  Branches       127       130    +3
=========================================
+ Hits           460       491   +31

Impacted Files
Coverage Δ

src/patito/__init__.py
100.00% <100.00%> (ø)

src/patito/polars.py
100.00% <100.00%> (ø)

src/patito/pydantic.py
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Implement Model::setHttpClient()

This change is necessary (for us) to strip out the httpClient/Guzzle from the results since we're going to cache them and it causes a lot of unnecessary wasted storage - and can't be serialized:
Serialization of 'Closure' is not allowed

Hey @mutec,
good idea! You should only remember that those cached instances than are not "usable" until you set the client again.


NPM package is not published

Expected Behaviour
NPM package is published
Actual Behaviour
NPM package is not published
According to https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/developing/generating-access-tokens-for-server-side-apis.html?lang=en#developer-flow
We can install this package from npm:
const exchange = require("@adobe/aemcs-api-client-lib");

What are the plans for publishing this as an npm package?

We restructured the repo after d8178a0182b257809d7a9685eba858e03b9c6b0e so that its now possible to reference the library in package.json using the github url, see https://docs.npmjs.com/cli/v6/configuring-npm/package-json#git-urls-as-dependencies for documentation.
For this repo it would be something like...
{
  "name": "foo",
  "version": "0.0.0",
  "dependencies": {
    "@adobe/aemcs-api-client-lib": "git://github.com/adobe/aemcs-api-client-lib.git#main",
...
...
  }
}

We will look into publishing as soon as possible.
Does this work for you while we do ?

Thanks, this helps for now.

I would like to integrate this lib into our angular application in order to communicate with AEM. Therefore, I need to generate the access token through this lib. Any suggestions?

We restructured the repo after d8178a0 so that its now possible to reference the library in package.json using the github url, see https://docs.npmjs.com/cli/v6/configuring-npm/package-json#git-urls-as-dependencies for documentation.
For this repo it would be something like...
{
  "name": "foo",
  "version": "0.0.0",
  "dependencies": {
    "@adobe/aemcs-api-client-lib": "git+https://github.com/adobe/aemcs-api-client-lib.git#main",
...
...
  }
}

We will look into publishing as soon as possible.
Does this work for you while we do ?

I recommend adding the instruction into the readme.md file.
It is a normal question that people who must use AEM API will come up. Installing a NPM from a Git url is not as intuitive than a more conventional NPM package. Adding the information into the readme.me will avoid people to be confuse and on your side diminish support, like having to answer this post.

Bumping this, our GHA runners don't have access to GitHub via npm so the workaround won't work for my use case. I've forked and published to our internal Artifactory in the meantime, but do not consider that a long term solution.


'Mutators' seems to be missing from the wiki

They used to be there AFAIR.

mutators was renamed miscellaneous a bit over a month ago.


Automated cherry pick of #9159: feat(region): add instance storage capability

Cherry pick of #9159 on release/3.4.
#9159: feat(region): add instance storage capability

Codecov Report

Merging #9508 (8226f06) into release/3.4 (fc16c37) will decrease coverage by 1.97%.
The diff coverage is 0.46%.

@@              Coverage Diff               @@
##           release/3.4   #9508      +/-   ##
==============================================
- Coverage         6.19%   4.21%   -1.98%
==============================================
  Files              761     456     -305
  Lines           118405   84081   -34324
==============================================
- Hits              7330    3545    -3785
+ Misses          110412   80232   -30180
+ Partials           663     304     -359

Flag
Coverage Δ

aFlag
4.21% <0.46%> (-1.98%)
:arrow_down:

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

Impacted Files
Coverage Δ

pkg/cloudcommon/db/sharablebase.go
6.01% <0.00%> (-0.06%)
:arrow_down:

pkg/cloudcommon/notifyclient/notify.go
1.78% <0.00%> (-0.03%)
:arrow_down:

pkg/cloudprovider/instance.go
0.00% <ø> (ø)

pkg/compute/models/capabilities.go
0.00% <0.00%> (ø)

pkg/compute/models/cloudaccounts.go
0.47% <0.00%> (-0.02%)
:arrow_down:

pkg/compute/models/cloudregions.go
1.52% <0.00%> (-0.02%)
:arrow_down:

pkg/compute/models/cloudsync.go
0.00% <0.00%> (ø)

pkg/compute/models/dbinstance_skus.go
2.79% <0.00%> (-0.04%)
:arrow_down:

pkg/compute/models/domainquota.go
23.80% <0.00%> (ø)

pkg/compute/models/elasticcache_skus.go
3.13% <0.00%> (-0.05%)
:arrow_down:

... and 321 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 fdf5156...8226f06. Read the comment docs.


asyncio.run() cannot be called from a running event loop

I am using  python 3.11.7 and the latest version of the Ollama pythons SDKs to run the sample code about AsyncClient
from ollama import AsyncClient
import asyncio

async def chat():
    message ={ "role":"user","content":"why people smile?"}
    response = await AsyncClient().chat(model="llama2",message=[message])

asyncio.run(chat())

I got an error as below.
RuntimeError                              Traceback (most recent call last)
Cell In[7], line 8
5     message ={ "role":"user","content":"why people smile?"}
6     response = await AsyncClient().chat(model="llama2",message=[message])
----> 8 asyncio.run(chat())
File ~/anaconda3/envs/tedia/lib/python3.11/asyncio/runners.py:186, in run(main, debug)
161 """Execute the coroutine and return the result.
162
163 This function runs the passed coroutine, taking care of
(...)
182     asyncio.run(main())
183 """
184 if events._get_running_loop() is not None:
185     # fail fast with short traceback
--> 186     raise RuntimeError(
187         "asyncio.run() cannot be called from a running event loop")
189 with Runner(debug=debug) as runner:
190     return runner.run(main)
RuntimeError: asyncio.run() cannot be called from a running event loop

fixed it, and added some sample code in this pr #36


directly query LDAP in ocis-reva

Currently ocis-reva appears to need nscd/nslcd running alongside it to query LDAP for user lookups. It would be interesting to try doing queries directly using a library instead.

closing as superceding issue is closed (https://github.com/cs3org/reva/issues/964)

closing as superceding issue is closed (https://github.com/cs3org/reva/issues/964)


root user has all privileges except for grant_priv

We may just need to explicitly update the mysql.user table during --initialize as this stackoverflow issue suggests.

This "grant option" might also be helpful.
https://dev.mysql.com/doc/refman/5.1/en/privileges-provided.html#priv_grant-option
https://github.com/aptible/docker-mysql/blob/53ee577664895292b0ef344c8838436836d5a4c8/5.6/run-database.sh#L13-L14

Fixed in #15


Dataset link is invalid

Hello, I want to download the dataset you provided, but the download link of the data set has expired. Can you update the download link?

Hello, which link are you referring to?
Peng R @.***> 于2023年8月14日周一 11:03写道：

Hello, I want to download the dataset you provided, but the download link
of the data set has expired. Can you update the download link?
—
Reply to this email directly, view it on GitHub
https://github.com/ChunmingHe/FEDER/issues/6, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANETWC76B5SOFAJVWR3HAKDXVGIQ7ANCNFSM6AAAAAA3PC3NTY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi, the download links for the training and test sets are not working, can you provide a new link?


Components.getComponent can fetch an uninitialized component

Minimal repro:
import type { Components } from '@flamework/components';
import { BaseComponent, Component } from '@flamework/components';
import type { OnStart } from '@flamework/core';
import { Service } from '@flamework/core';
import { Workspace } from '@rbxts/services';

@Component({
	tag: 'Test',
})
export class TestA extends BaseComponent implements OnStart {
	constructor(private readonly components: Components) {
		super();
	}

	onStart() {
		print(this.components.getComponent<TestB>(this.instance)!.myValue);
	}
}

@Component({
	tag: 'Test',
})
export class TestB extends BaseComponent implements OnStart {
	myValue = 'i exist';

	constructor(private readonly testA: TestA) {
		super();
	}

	onStart() {}
}

@Service({})
export class TestService implements OnStart {
	constructor(private readonly components: Components) {}
	onStart() {
		const part = new Instance('Part');
		part.AddTag('Test');
		part.Parent = Workspace;
		this.components.getComponent<TestB>(part);
	}
}

Output: nil
Here is an overview of the issue:

TestB is added to ID mapping
setupComponent is called on TestB
Eagerly load TestA as it is a dependency of TestB and has the corresponding tag
TestA runs its constructor
TestA runs OnStart
TestB is in ID mapping despite being half constructed
TestB runs its constructor

I suspect this can be fixed if these lines are moved under setupComponent: https://github.com/rbxts-flamework/components/blob/283b54adaad51978de8f773c95c7bf486d8391b6/src/components.ts#L594-L596

This is because TestA and TestB cyclically depend on eachother's construction.  The component has to be eagerly put into the registry to avoid infinite recursion in cases like this, so I've added a separate check for whether a component is still in construction, in which case it will return undefined, or error in the case of addComponent.
The polymorphic IDs are specifically for the polymorphic APIs (which doesn't include getComponent) such as getAllComponents and getComponents so moving that below setupComponent wouldn't fix this specific case, but it does fix similar cases with those APIs.
Fixed in https://github.com/rbxts-flamework/components/commit/f61187fd6a6f8596ffd68a237d692ace46182d63


If there is nothing in the side columns, they still show as empty space

In the new layout columns, when there is nothing displayed the map is still a reduced size. If there is nothing there, the map should extend the width of the screen.

Hi.
I find this issue very troubling for me, my corporation, and two corps "affiliated". There should be an option for changing layout to get full width of map like it was before.
Imagine a map with a lot of systems, or just lower-resolution monitors.
We need it, badly.

This has been addressed in another report. You change the resolution of your monitor and it will get rid of the right column but that is the only way. As far as I know right now it is not changing for a little bit. I might be changing at a later date but that is yet to be seen.

@CalMatar Care to link the issue so that we can close this if it's redundant?

It was ticket #935 That ticket was closed. You can look it up. If you click on closed tickets it is one of the top ones.

Duplicates https://github.com/exodus4d/pathfinder/issues/935


Refactor/preventing duplicate client order ids

Before submitting this PR, please make sure:

[X] Your code builds clean without any errors or warnings
[X] You are using approved title ("feat/", "fix/", "docs/", "refactor/")

A description of the changes proposed in the pull request:
Duplicated client order IDs can cause orders to be rejected by the exchange and can cause issues with historical analysis of strategy performance. Currently, the client uses a nonce derived from the current timestamp to generate "unique" client order IDs. The issue is that those IDs can be duplicated across multiple instances of hummingbot running in parallel. To prevent this from happening, this PR introduces a new method of generating the IDs that will be unique across instances as well.
The two main changes are:

Propagates the Binance approach of ensuring unique client order Ids into the rest of the CoinAlpha-maintained exchanges with slight modifications.
Adds a default function to use for that purpose with options for adding an exchange-specific prefix and limiting the length of the ID string.

The new order ID schema

Optional exchange-specific hbot_order_id_prefix
Order side ["B", "S"]
The base_str, which is the first and last letter of the base token
The quote_str, which is the first and last letter of the quote token
Tracking nonce (low-res version, with milliseconds)
The client_instance_id, which are generated so that they differ between instances on the same machine, but also between instances on different machines (eng: see concerns below)

Tests performed by the developer:

Tests for the new function
Tests for all of the exchanges affected:

AscendEx
Binance spot
Binance perp
Bybit perp
Gate.io
Huobi
KuCoin
OKEX
ProBit

Successfully placed orders on the following exchanges (expired creds for ByBit perp; invalid ones for Huobi and OkEx):

AscendEx
Binance spot
Binance perp (testnet)
Gate.io
KuCoin
ProBit

Tested and confirmed working QA.
Tests performed:

Created a strategy using the affected connectors and went through initial prompts successfully
Started the strategy without issues, confirmed orders are created and cancelled based on config
Confirmed that the orders created now uses the new order ID schema
Confirmed that no duplicate client order IDs were created when running between instances on the same and different machine
Trade information are correct (price, size and order ID) based on history command output, sqlite and csv file
Confirmed all issues reported are now fixed

Hi @petioptrv. Please resolve branch conflicts in this PR. Thanks!

@JeremyKono, dues to the fact that this branch was originally branched off of a feature branch, resolving the issues has been a nightmare, so I created a new PR that branched directly off of development instead.

Closing this PR, and re-creating it here


File reorganisation

This PR reorganises the files in the ga4gh package into a more logical order and opens the way for adding support for reads and references. Apologies for basing the diff on #59 - this was already quite a large change, so I thought it simpler to go with this route.  Hopefully that will be merged soon and we'll be able to see the changes here more clearly.
The basic gist of this PR is that we layout the code as follows:
ga4gh/
     __init__.py
     backend.py
     frontend.py
     protocol.py
     datamodel/
           __init__.py
          variants.py
          reads.py
          references.py

(I've left out a few files here that haven't been  affected.).
The idea is that we pull the classes in backends.py that are dealing with the GA4GH 'data model' and put them into their own package. We further split this package up into variants.py, reads.py, and references.py. I think it's a good idea to split these up as they are logically distinct and now that there's a lot of us working on the code, it'll be good to avoid merge issues.
I've renamed backends to backend since there is now a single Backend object. Similarly, I've renamed the server package to frontend, since it contains the Flask frontend.
I changed the Flask frontend to use a single file for now. I did argue for separating it out into views.py and __init__.py when we were making the transition to Flask, but I don't think we're getting a lot of value out of this at the moment. We can always split things out again later if frontend.py is getting too complicated.
I've made the minimal changes to the test cases to make them work. I think we should refactor and reorganise these as a separate PR later.
This is just a proposal to start a discussion, so please weigh in if you disagree with this layout!

Can I please get 2 hours of stability to add a new backend?  Please?  This rate of churn is making it unnecessarily hard for an "outsider" to contribute.
Sent from my tiny remote device.

On Jan 13, 2015, at 10:26 AM, Jerome Kelleher<EMAIL_ADDRESS>wrote:
This PR reorganises the files in the ga4gh package into a more logical order and opens the way for adding support for reads and references. Apologies for basing the diff on #59 - this was already quite a large change, so I thought it simpler to go with this route. Hopefully that will be merged soon and we'll be able to see the changes here more clearly.
The basic gist of this PR is that we layout the code as follows:
ga4gh/
init.py
backend.py
frontend.py
protocol.py
datamodel/
init.py
variants.py
reads.py
references.py
(I've left out a few files here that haven't been affected.).
The idea is that we pull the classes in backends.py that are dealing with the GA4GH 'data model' and put them into their own package. We further split this package up into variants.py, reads.py, and references.py. I think it's a good idea to split these up as they are logically distinct and now that there's a lot of us working on the code, it'll be good to avoid merge issues.
I've renamed backends to backend since there is now a single Backend object. Similarly, I've renamed the server package to frontend, since it contains the Flask frontend.
I changed the Flask frontend to use a single file for now. I did argue for separating it out into views.py and init.py when we were making the transition to Flask, but I don't think we're getting a lot of value out of this at the moment. We can always split things out again later if frontend.py is getting too complicated.
I've made the minimal changes to the test cases to make them work. I think we should refactor and reorganise these as a separate PR later.
This is just a proposal to start a discussion, so please weigh in if you disagree with this layout!
You can merge this Pull Request by running
git pull https://github.com/jeromekelleher/server file-cleanup
Or view, comment on, or merge it at:
https://github.com/ga4gh/server/pull/68
Commit Summary
Unified paging + refactored Backend object.
Updated style on variant set unit tests.
Modified front-end tests for new backend API.
Moved variant processing out of backend.
Changed server package to 'frontend'.
Added stubs for reads and references.
File Changes
A ga4gh/backend.py (147)
M ga4gh/cli.py (30)
A ga4gh/datamodel/init.py (7)
A ga4gh/datamodel/reads.py (14)
A ga4gh/datamodel/references.py (14)
R ga4gh/datamodel/variants.py (282)
A ga4gh/frontend.py (100)
D ga4gh/server/init.py (12)
D ga4gh/server/views.py (103)
M tests/init.py (4)
M tests/test_backends.py (281)
M tests/test_views.py (37)
Patch Links:
https://github.com/ga4gh/server/pull/68.patch
https://github.com/ga4gh/server/pull/68.diff
—
Reply to this email directly or view it on GitHub.

Sorry @bioinformed, we're trying to push through all these changes so that the code will be stable for the next few months, and we can all make progress without stepping over each other. If you work off the existing master and avoid changing too much I think git will figure out how to merge it back in easily enough. If not, everything you do can just be put into datamodel/variants.py when you're done.
I would just work ahead with what you're doing, and ignore these changes for now.

I'll review outstanding PRs tonight, so let's freeze development on
backends after Jerome's two PRs get in. Kevin, I've got a PR for the Tabix
backend that I am likewise waiting on, so I'll put that in after you.
Kerry
On Tue, Jan 13, 2015 at 10:41 AM, Kevin Jacobs<EMAIL_ADDRESS>wrote:

Can I please get 2 hours of stability to add a new backend? Please? This
rate of churn is making it unnecessarily hard for an "outsider" to
contribute.
Sent from my tiny remote device.

On Jan 13, 2015, at 10:26 AM, Jerome Kelleher<EMAIL_ADDRESS>wrote:
This PR reorganises the files in the ga4gh package into a more logical
order and opens the way for adding support for reads and references.
Apologies for basing the diff on #59 - this was already quite a large
change, so I thought it simpler to go with this route. Hopefully that will
be merged soon and we'll be able to see the changes here more clearly.
The basic gist of this PR is that we layout the code as follows:
ga4gh/
init.py
backend.py
frontend.py
protocol.py
datamodel/
init.py
variants.py
reads.py
references.py
(I've left out a few files here that haven't been affected.).
The idea is that we pull the classes in backends.py that are dealing
with the GA4GH 'data model' and put them into their own package. We further
split this package up into variants.py, reads.py, and references.py. I
think it's a good idea to split these up as they are logically distinct and
now that there's a lot of us working on the code, it'll be good to avoid
merge issues.
I've renamed backends to backend since there is now a single Backend
object. Similarly, I've renamed the server package to frontend, since it
contains the Flask frontend.
I changed the Flask frontend to use a single file for now. I did argue
for separating it out into views.py and init.py when we were making the
transition to Flask, but I don't think we're getting a lot of value out of
this at the moment. We can always split things out again later if
frontend.py is getting too complicated.
I've made the minimal changes to the test cases to make them work. I
think we should refactor and reorganise these as a separate PR later.
This is just a proposal to start a discussion, so please weigh in if you
disagree with this layout!
You can merge this Pull Request by running
git pull https://github.com/jeromekelleher/server file-cleanup
Or view, comment on, or merge it at:
https://github.com/ga4gh/server/pull/68
Commit Summary
Unified paging + refactored Backend object.
Updated style on variant set unit tests.
Modified front-end tests for new backend API.
Moved variant processing out of backend.
Changed server package to 'frontend'.
Added stubs for reads and references.
File Changes
A ga4gh/backend.py (147)
M ga4gh/cli.py (30)
A ga4gh/datamodel/init.py (7)
A ga4gh/datamodel/reads.py (14)
A ga4gh/datamodel/references.py (14)
R ga4gh/datamodel/variants.py (282)
A ga4gh/frontend.py (100)
D ga4gh/server/init.py (12)
D ga4gh/server/views.py (103)
M tests/init.py (4)
M tests/test_backends.py (281)
M tests/test_views.py (37)
Patch Links:
https://github.com/ga4gh/server/pull/68.patch
https://github.com/ga4gh/server/pull/68.diff
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/server/pull/68#issuecomment-69763660.

Many thanks. Please don't misunderstand: I like the unified paging PR and the other reorganizations. However, they do make working on the master branch less attractive. More so, because git can't carry forward the changes in a merge, because I'm adding an entirely new backend. Thus it would be really nice for the unified paging PR to land and for there to be a small window of stability.
Sent from my tiny remote device.

On Jan 13, 2015, at 10:51 AM, Kerry Donny-Clark<EMAIL_ADDRESS>wrote:
I'll review outstanding PRs tonight, so let's freeze development on
backends after Jerome's two PRs get in. Kevin, I've got a PR for the Tabix
backend that I am likewise waiting on, so I'll put that in after you.
Kerry
On Tue, Jan 13, 2015 at 10:41 AM, Kevin Jacobs<EMAIL_ADDRESS>wrote:

Can I please get 2 hours of stability to add a new backend? Please? This
rate of churn is making it unnecessarily hard for an "outsider" to
contribute.
Sent from my tiny remote device.

On Jan 13, 2015, at 10:26 AM, Jerome Kelleher<EMAIL_ADDRESS>wrote:
This PR reorganises the files in the ga4gh package into a more logical
order and opens the way for adding support for reads and references.
Apologies for basing the diff on #59 - this was already quite a large
change, so I thought it simpler to go with this route. Hopefully that will
be merged soon and we'll be able to see the changes here more clearly.
The basic gist of this PR is that we layout the code as follows:
ga4gh/
init.py
backend.py
frontend.py
protocol.py
datamodel/
init.py
variants.py
reads.py
references.py
(I've left out a few files here that haven't been affected.).
The idea is that we pull the classes in backends.py that are dealing
with the GA4GH 'data model' and put them into their own package. We further
split this package up into variants.py, reads.py, and references.py. I
think it's a good idea to split these up as they are logically distinct and
now that there's a lot of us working on the code, it'll be good to avoid
merge issues.
I've renamed backends to backend since there is now a single Backend
object. Similarly, I've renamed the server package to frontend, since it
contains the Flask frontend.
I changed the Flask frontend to use a single file for now. I did argue
for separating it out into views.py and init.py when we were making the
transition to Flask, but I don't think we're getting a lot of value out of
this at the moment. We can always split things out again later if
frontend.py is getting too complicated.
I've made the minimal changes to the test cases to make them work. I
think we should refactor and reorganise these as a separate PR later.
This is just a proposal to start a discussion, so please weigh in if you
disagree with this layout!
You can merge this Pull Request by running
git pull https://github.com/jeromekelleher/server file-cleanup
Or view, comment on, or merge it at:
https://github.com/ga4gh/server/pull/68
Commit Summary
Unified paging + refactored Backend object.
Updated style on variant set unit tests.
Modified front-end tests for new backend API.
Moved variant processing out of backend.
Changed server package to 'frontend'.
Added stubs for reads and references.
File Changes
A ga4gh/backend.py (147)
M ga4gh/cli.py (30)
A ga4gh/datamodel/init.py (7)
A ga4gh/datamodel/reads.py (14)
A ga4gh/datamodel/references.py (14)
R ga4gh/datamodel/variants.py (282)
A ga4gh/frontend.py (100)
D ga4gh/server/init.py (12)
D ga4gh/server/views.py (103)
M tests/init.py (4)
M tests/test_backends.py (281)
M tests/test_views.py (37)
Patch Links:
https://github.com/ga4gh/server/pull/68.patch
https://github.com/ga4gh/server/pull/68.diff
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/server/pull/68#issuecomment-69763660.

—
Reply to this email directly or view it on GitHub.

This PR shouldn't affect what you're doing much @bioinformed, it's just moving stuff around in files. You can safely ignore it. #59 is different, as it changes the VariantSet API and should make it much, much simpler to work with. I would recommend setting up a upstream for my server repo (https://github.com/jeromekelleher/server) and rebasing your branch off my paging-cleanup branch. This should give you a stable platform to work with. I won't do any more rebasing, so you should then be able to merge your work easily.
To define the backend, just do a copy paste on the existing TabixVariantSet; yours should be very similar. We can figure out a good way to merge the two later.
Thanks for working on this htslib interface, and sorry again for all the churn!

Thanks! Working from your branch will work fine, since you're not going to rebase.
Sent from my tiny remote device.

On Jan 13, 2015, at 11:09 AM, Jerome Kelleher<EMAIL_ADDRESS>wrote:
This PR shouldn't affect what you're doing much @bioinformed, it's just moving stuff around in files. You can safely ignore it. #59 is different, as it changes the VariantSet API and should make it much, much simpler to work with. I would recommend setting up a upstream for my server repo (https://github.com/jeromekelleher/server) and rebasing your branch off my paging-cleanup branch. This should give you a stable platform to work with. I won't do any more rebasing, so you should then be able to merge your work easily.
To define the backend, just do a copy paste on the existing TabixVariantSet; yours should be very similar. We can figure out a good way to merge the two later.
Thanks for working on this htslib interface, and sorry again for all the churn!
—
Reply to this email directly or view it on GitHub.

+1

+1

Jerome, if you could clean this up now that #59 is merged, I'll merge it today.

OK, this should be ready to merge. Please make sure to delete the .pyc files and server directory in your ga4gh directory, or weird things might happen.

This has been a bit of a mess to merge - hopefully should be sorted out now.


Windows installer fails to install

Hello,
Just wanted to upgrade my Atom to the latest version (I can't tell the version, the download link mentions "release 3228505") but the installer fails with the following error:
Program: Starting Squirrel Updater: --install .
Program: Starting install, writing to C:\Users\nicolae.surdu\AppData\Local\SquirrelTemp
CheckForUpdateImpl: Failed to load local releases, starting from scratch: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\nicolae.surdu\AppData\Local\atom\packages\RELEASES'.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
   at Squirrel.Utility.LoadLocalReleases(String localReleaseFile)
   at Squirrel.UpdateManager.CheckForUpdateImpl.<CheckForUpdate>d__28.MoveNext()
CheckForUpdateImpl: Reading RELEASES file from C:\Users\nicolae.surdu\AppData\Local\SquirrelTemp
CheckForUpdateImpl: First run or local directory is corrupt, starting from scratch
ApplyReleasesImpl: Writing files to app directory: C:\Users\nicolae.surdu\AppData\Local\atom\app-0.187.0
IEnableLogger: Failed to update local releases file: System.IO.IOException: The file exists.

   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.__Error.WinIOError()
   at System.IO.Path.InternalGetTempFileName(Boolean checkHost)
   at Squirrel.ReleaseEntry.BuildReleasesFile(String releasePackagesDir)
   at Squirrel.UpdateManager.ApplyReleasesImpl.<updateLocalReleasesFile>b__ec()
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Squirrel.UpdateManager.ApplyReleasesImpl.<updateLocalReleasesFile>d__ed.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Squirrel.Utility.<LogIfThrows>d__4f`1.MoveNext()

Uninstalling the old version and attempting again does not fix the issue

Could you try deleting everything inside %temp% or running Disk Cleanup and trying again?
If that still doesn't work, what antivirus do you have installed?
/cc @paulcbetts

Running the disk cleanup solved the problem. Just for the sake of completeness, I am running McAfee antivirus.


Add unsafe initialisers for HTTPField and HTTPField.Name

Currently when constructing an HTTPField or HTTPField.Name the values are checked to see if they are valid. This is the correct thing to do obviously when the source of the headers is unknown, but if we know in advance the headers are valid this is wasted effort.
The situation I am describing comes from building a SwiftNIO server which has constructed the header values via LLHTTP which validates they are correct and then we build a HTTPField from these that does the validation again.
Is there an argument for providing an unsafe initialiser for both HTTPField and HTTPField.Name to avoid this duplicate work

Yeah, that could be useful. Something like HTTPField.Name.init(unchecked name: String)?
I wouldn't expect llhttp to clear everything up though. If the field value contains lone CRs, we still have to parse it but would want to replace those with spaces before passing them to the client.

I wouldn't expect llhttp to clear everything up though.

I don’t know, maybe @Lukasa knows

I agree with @guoye-zhang that we probably can't use this proposed unchecked initialiser since the validation that lhttp does isn't fully matching what the current HTTPTypes inits do.
@adam-fowler You mentioned to me that you see a lot of time spent in these validating inits. It's worth getting an issue opened for that as well to see if we can optimise this more.


Can i use codicons for private projectes (if yes, how)?

Yes, you can use the npm package.  Take a look at the README on how to reference them in code, let me know if you've got any other questions.


[CARBONDATA-2676]Support local Dictionary for SDK Writer

Currently local dictionary is supported for managed table which is created using sql .
We it should be supported for SDK Writer also.
This PR contains
a. Interface to supply dictionary threshold & Boolean  to enable dictionary.
b. DataLoading flow
Yet to support
a. Query Flow of Local dictionary (it will be done when normal table start supports for same)
b. External Table loading and Query .
Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[ ] Any interfaces changed?
Existing Interface is not changed added new method
[ ] Any backward compatibility impacted?
NA
[ ] Document update required?
NO
[ ] Testing done
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
Added UT
- How it is tested? Please attach test report.
UT is added
- Is it a performance related change? Please attach the performance test report.
NO
Any additional information to help reviewers in testing this change.
NO
[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.
NO

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/5544/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/6691/

Also for the new interface methods added for the local dictionary. Need to update this in SDK guide.
https://github.com/apache/carbondata/blob/master/docs/sdk-guide.md

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/5681/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/6915/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/5700/

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/5682/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/6968/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/5724/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/7001/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/5781/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/5756/


implementation of snapshottable

This fixes #379 and #1053.
Open points

snapshot_integration_test fails against emulator.
snapshot_integration_test works with production but not integrated with run_integration_test_production  as it might consume allowed quota.

This change is

PTAL


Remove Cookie not working properly

const [cookies, setCookie, removeCookie] = useCookies();

setCookie('key', value, {
          path: '/',
          maxAge: 86400 * 365,
        });

removeCookie('key');

Sometime cookie does not removing

hey , were you able to solve the issue ?

No, the issue is still there

I just ran into this issue. For me it seems like adding the path as option in removeCookie fixed it.
So  removeCookie('key', { path: '/' })
It is weird as it is not an issue that happened on all occasions, but only sometimes.

I just ran into this issue. For me it seems like adding the path as option in removeCookie fixed it.
So removeCookie('key', { path: '/' })
It is weird as it is not an issue that happened on all occasions, but only sometimes.

Yes you are correct.
Also the solution you provided, looks working for me.

I just ran into this issue. For me it seems like adding the path as option in removeCookie fixed it.
So removeCookie('key', { path: '/' })
It is weird as it is not an issue that happened on all occasions, but only sometimes.

it not working for me

@Nahov91 Thanks, your workaround fixed this issue for me too.

I suppose the docs missing the value for the removeCookie function. You can remove the cookie like this
removeCookie('key', '')

The options { path: '/' }  just write the new value for the cookie as %7B%22path%22%3A%22%2F%22%7D
Hope this help

You have to specify the path for removing as well. It would solve your issue.

Cant the path '/' be default? I'm not setting a path when creating the cookie, so it feels very weird to have to tell it when removing.


[ISSUE #964]🚀Support client consumer message-2🚀

Which Issue(s) This PR Fixes(Closes)

Fixes #964
Brief Description

How Did You Test This Change?

🚀Thanks for your contribution🎉. CodeRabbit(AI) will review your code first🔥


Hello, friend

hello Can I make some changes in this code for my own use

hello Can I make some changes in this code for my own use

just fork bro =)


Add interceptor support

This change exposes gRPC interceptors at stub creation time.
@landrito for the corresponding generator change could we follow what you did for python? What would the Ruby code look like to add an interceptor to a client?
[will squash all the junk commits]

Codecov Report

Merging #127 into master will increase coverage by 0.05%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master    #127      +/-   ##
=========================================
+ Coverage   99.35%   99.4%   +0.05%
=========================================
  Files          19      19
  Lines        2014    2028      +14
=========================================
+ Hits         2001    2016      +15
+ Misses         13      12       -1

Impacted Files
Coverage Δ

spec/google/gax/grpc_spec.rb
100% <100%> (ø)
:arrow_up:

lib/google/gax/grpc.rb
100% <100%> (ø)
:arrow_up:

spec/google/gax/bundling_spec.rb
100% <0%> (+0.3%)
:arrow_up:

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 ed62589...e3bb524. Read the comment docs.

Updated (also added channel_override since it was missing too).


[CTA] v2 Epic

Epic to track changes to CTA in Carbon for IBM.com v2
### Design
- [ ] https://github.com/carbon-design-system/carbon-for-ibm-dotcom-website/issues/1557
- [ ] Figma

### Dev
- [ ] https://github.com/carbon-design-system/carbon-for-ibm-dotcom/issues/10359
- [ ] https://github.com/carbon-design-system/carbon-for-ibm-dotcom/issues/10432 UPDATED
- [ ] QA

closing epic in favor of new organization strategy


[Question]: Advantages compared to Xpenology

Is your question not already answered in the FAQ?

[X] I made sure the question is not listed in the FAQ.

Is this a general question and not a technical issue?

[X] I am sure my question is not about a technical issue.

Question
I have been running an older version of Xpenology 6.2.3 as a VM in Proxmox and wish to switch to the latest DSM 7 versions to match my physical Synology NAS.
What are the advantages and disadvantages of going with a virtual-dsm Docker container (in Proxmox)?
How challenging will it be to transfer the files from the old Xpenology to the new virtual-dsm instance?

Having used both myself (redpill xpenology) and this docker, this docker wins hands down for simplicity, with Xpenology and redpill you had to check how others faired with DSM upgrades where this docker just updates like a normal Synology Nas. I run it in pure docker environment as no longer use proxmox but it runs like a dream.
With regards to moving files, just set up a vdsm docker on your proxmox, and once set up folder wise etc use one of the synology to synology back up apps or just mount both SMB shares and copy accross. Plenty of ways to achieve that end goal


Translate 1 file to ko - Mobile Support

issue: #6
en

Mobile Support

맞춤법 검사기로 체크하였습니다~ 검토하시다가 수정해야할 사항 있다면 코멘트 부탁드립니다!

LGTM

@orta
Could you merge these PRs? Merging actions failed. https://github.com/microsoft/TypeScript-Website-Localizations/pull/91, https://github.com/microsoft/TypeScript-Website-Localizations/pull/80

Thanks, I've added some better logging - so the next time it happens we might know why


backbone

Hello Rosinality,
I can not find the "vovnet39_torchvision.pth" file, Can you share the weight file?
And if I can take resnet101 as the backbone? How to do
thanks

Hey did you find this file?

You can use checkpoints in here: https://github.com/stigma0617/VoVNet.pytorch. And if you want to use resnet101, then you need to modify resnet code to return stride 16, 32 feature maps so it could be used in here: https://github.com/rosinality/ocr-pytorch/blob/master/model.py#L51.


theming for the watchers article

Coverage remained the same at 65.132% when pulling 11db5bf6e8b962114a2c4dc10fc5127f6bbcb172 on oc-86 into 5087bba7820d2aa43d3cd2ae339c181cf810f5b3 on master.

Coverage remained the same at 65.132% when pulling 82259cdf98f8f9a1fc383d263817365e4ab64483 on oc-86 into 5087bba7820d2aa43d3cd2ae339c181cf810f5b3 on master.


Screen Off Feature

Description of the new feature / enhancement
The Screen Should Just Go Black And Not In Sleep Mode With A Click Of A Button So That All The Processes Can Run In The Background
Scenario when this would be used?
We Can Conserve The Battery By Just Turning Off The Screen And All The Process Like Running The Code/Video/Music Should be Running  In The Background
Supporting information
No response

Thank you for your feedback! Your idea is considered but currently is not planned for integration into the PowerToys.


Change PIN to use config setting

The pairing pin for the Bluetooth connection is currently hard coded, this means someone has to know how to recompile and deploy to change the value.
This value should likely come from the master device and passed into the Bluetooth device during init prior to starting advertise.

This is dependent on #90 as a prerequisite

#97 relocated the PIN to come from the configuration settings class, so now it's just dependent on the configuration settings being loaded from another bit of hardware.

Already completed with #90


Interactive window errors when building catboost regressors in python

Bug: Notebook Editor, Interactive Window, Editor cells

Steps to cause the bug to occur

Actual behavior
Expected behavior

Your Jupyter and/or Python environment
Please provide as much info as you readily know

Jupyter server running: Local | Remote | N/A
Extension version: 20YY.MM.#####-xxx
VS Code version: #.##
Setting python.jediEnabled: true | false
Setting python.languageServer: Jedi | Microsoft | None
Python and/or Anaconda version: #.#.#
OS: Windows | Mac | Linux (distro):
Virtual environment: conda | venv | virtualenv | N/A | ...

Developer Tools Console Output

Microsoft Data Science for VS Code Engineering Team: @rchiodo, @IanMatthewHuff, @DavidKutu, @DonJayamanne, @greazer, @joyceerhl

Hi, thanks for the bug report! Please provide the error logs and steps to reproduce the bug so that we can help to identify the problem.


setup a script to build the app in the ci.centos.org infra

once we have the build working, we can get it containerised and into the local registry for deployment

This change is

replaced by https://github.com/almighty/almighty-ui/commit/576fe07b9a49bd4ae928af3eebafd5ce0381acd8


Illegal start of statement

I'm trying to expand a function declaration into a private class and it's factory function:
object test {
  @constr def Print(s: String): Call[Unit]
}

where @constr should expand into a private class with a def, so the annotation result value looks this: q"$genClass; $getFunc". It fails to compile:
[error] <macro>:2: illegal start of statement (no modifiers allowed here)
[error]   private final class $constr$PrintLine(val value: String) extends SystemCall[Unit] {}
[error]   ^

So it looks something like this after expansion:
object test {
  {
    private class generatedClass
    def generatedFunc
  }
}

maybe i'm simply missing some restriction

Could you provide a reproduction and resubmit to https://github.com/scalameta/paradise/issues?


Implement Events

Has Tessera implemented events?  I can't seem to figure out how to use them.  It seems I'm stuck with metrics.
http://graphite/events/
http://chasemp.github.io/2013/05/17/using-graphite-events/

Sorry no, tessera currently has no support for graphite events.

OK, thanks for the response.  I really appreciate Tessera and the work behind it.  Perhaps this could be labeled as a potential enhancement.


Upgrade to JDK 17

Upgrade graldle image and test to JDK 17. Adoptopendjk is retired, so use its successsor eclipse-temurin in the test cases. Sonarqube image couldn't be upgrade since Sonarqube does only support Java 11 so far.
Closes 294
Tasks:

[x] Updated design documents in docs/design directory or not applicable
[x] Updated user-facing documentation in docs directory or not applicable
[x] Ran tests (e.g. make test) or not applicable
[x] Updated changelog or not applicable

Sonarqube image couldn't be upgrade since Sonarqube does only support Java 11 so far.

Fine - we need to be aligned with ods-core here anyway.


Change call_tir convention; Unify shape/type deduction rule

As discussed in #88, this pr changes call_tir to have its output_shape and output_type specified in its argument and type_args respectively:
call_tir<out_type>(out_shape, func, [a, b]) -> Expr.
This changes makes the shape/type deduction rule more principled and simple: the shape_ and checked_type_ of a CallNode are always deduced(inferred). During the rewriting, whenever the inputs of a CallNode are changed, the shape_ and checked_type_ are always re-deduced.
In TVMScript, one can write the following for call_tir:
# call_tir has a single output
# note that dtype is a keyword argument, indicating it's not a arg of call_tir, but is part of the type_args
y = R.call_tir((32, 16), relu, (x), dtype="float32")

# call_tir has multiple outputs
z = R.call_tir(((1, 3, 224, 224), (3,), (3,)), batch_norm, (data, bn_data_gamma, bn_data_beta, bn_data_moving_mean, bn_data_moving_var), dtype=("float32", "float32", "float32"))

Other changes:

Removes the hardcoded Float32 dtype in the vm memory lowering pass. Adds an attr to relax.builtin.alloc_tensor to carry dtype to be used in the vm memory lowering pass. (check out the test_vm_emit_te_dtype_change added to test_vm.py)
Adds printer support for a tensor with TupleTypeNode (which is often the return value of a call_tir with multiple outputs), previously we didn't print its shape. The multi-output TVMScript in the above code-snippet prints as:

gv: Tuple[(Tensor[(1, 3, 224, 224), "float32"], Tensor[(3,), "float32"], Tensor[(3,), "float32"])] = relax.call_tir(((1, 3, 224, 224), (3,), (3,)), batch_norm, (data, bn_data_gamma, bn_data_beta, bn_data_moving_mean, bn_data_moving_var), dtype=("float32", "float32", "float32"))

We could discuss if we want to print the Tuple with shape info in the lhs of the binding if rhs is a call_tir, which also contains this information. Feedback is welcome!
cc @yongwww @Hzfengsy @hypercubestart  @ZihengJiang

As we discussed on this week's relax open dev meeting, we agreed on having output_shape as the 3rd argument of call_tir. And for the TVMScript printing sugar, we also converged on the following format, that is we don't print the shape, dtype info on the lhs Var of a binding if the rhs is a call_tir, and for the lhs, print the output shape/dtype in the end.
gv = relax.call_tir(batch_norm, (data, bn_data_gamma, bn_data_beta, bn_data_moving_mean, bn_data_moving_var), ((1, 3, 224, 224), (3,), (3,)), dtype=("float32", "float32", "float32"))

I made the changes, it would be great to have you guys take a review. cc @yongwww @Hzfengsy @hypercubestart @ZihengJiang. :)

Thanks @YuchenJin for the work and leading the discussion! Thanks folks for reviewing! @ZihengJiang @hypercubestart


hemophagocytosis

Add new term:
hemophagocytosis ( a child of abnormal macrophage physiology MP:0002451)
DEF: a pathologic process of engulfment of erythrocytes, leukocytes, platelets, and their precursors by the histiocytes, either in the bone marrow or in other parts of the reticuloendothelial system; it is a nonspecific phenotypic feature observed in several conditions including hemolytic anemia, malignant disease, infections, and hemophagocytic syndrome (also known as hemophagocytic lymphohistiocytosis, a rare hyperinflammatory syndrome caused by severe hypercytokinemia due to a highly stimulated but ineffective immune process)
SOURCE: http://www.mjdrdypv.org/text.asp?2019/12/1/22/250440, HP:0012156

Added new term:
hemophagocytosis MP:0031070


Graceful shutdown on SIGTERM

It's great that micro core now handles SIGTERM, and it would be even better if micro-dev did as well. Better yet if both micro and micro-dev handled SIGINT too to gracefully shut down 😎

@rauchg and I talked extensively about this. Graceful shutdown doesn't make sense in development, because it takes a lot of times to close down all open sockets. In turn, neither fast hot reloading, nor quitting the server and not having to wait for a long time works. I hope you understand... 😊

Hot reloading gets rid of most of the need to repeatedly shutdown the server in dev, so that's why I was thinking it would be fine to add graceful shutdown for micro-dev too.
My use case is running micro-dev in a Docker container. I would love for it to be shutdown gracefully instead of having to be docker kill'd.

@rauchg Can you jump in?
Guillermo had the same concern, but then he said that there are several different ways to handle such a situation with Docker - so that SIGTERM doesn't need to be handled.

Maybe the idea is to use the docker run --init option to manage the node process.