text:
Frontend: Refactor layout

Description

Removed sizing from HTML element to use div as container for more consistency
Removed the deactivation of the legend when option where toggled on and vice versa
Panels will stack on each other and when screen height is overflowing, scrolling will be activated
Interaction with the graph are not prevented if a panel is activated (around the panel)
Graph is visible under panel container

Screenshots
Scroll bar in panel space (smaller screen)

Interaction with graph and width consistency (bigger screen)

closes #53

Shoudnt the query panel stay a the the bottom?

Shoudnt the query panel stay a the the bottom?

Do you mean it should always be last in the list of panels? Because it is atm
But if you are talking about a position fixed, that is exactly why this PR is made for, get rid of all fixed position (which makes very difficult to implement new panels).
But I am open to any insights if you have an idea

No I meant the query panel should be fixed at the bottom, if its just a floating panel then it would be jumping all over the place as you toggle some other panels.

No I meant the query panel should be fixed at the bottom, if its just a floating panel then it would be jumping all over the place as you toggle some other panels.

Mmmh. This is basically the previous implementation which leads to a lot of problems when implementing other panels (like shortcut panels)
Having the panel fixed is taking it out of the flex container basically. IT makes the UI very difficult to extend and improve.
Also, how would you handle the different screen sizes? Having the panels floating with one fixed? I foresee a lot of issues with this kind of implementation.
We can have a chat on zoom if you want to iterate through ideas but as far as now, I don't see how this would be good implementation as suggested now :x

Flex allows you to put things at the end of the container, dont really see the issue, as long as the container holding the panels is full height.

Flex allows you to put things at the end of the container, dont really see the issue, as long as the container holding the panels is full height.

That for sure, but it will still be pushed down if overflows. But if that is okay, then I can for sure implement that =)

But if that is okay

yes, dont spend too much time on supporting small screens, the common case needs to be solid first.

But if that is okay

yes, dont spend too much time on supporting small screens, the common case needs to be solid first.

Some updates:
I played around with the code to try some different solutions and we have some trade off to make if we go for this (at this stage)

If we make the container full screen to put the filter at the bottom, we have to activate interaction with the container in order to overflow (which is necessary for adding new panels). This will prevent interaction with the graph (like hovering feature, and all) on the area covered by the container even if no panels are open. I personally think that the benefit to have a fixed position for the filter is not worth losing interaction with the graph on that area. (cf screenshot)

Any insights are welcome, but I don't see how to fix this without reworking the whole frontend structure (which is out of the scope of this PR, since this is to allow more panels to be added in a smooth way).
I suggest we make an issue for this and try to address it once the rework on the panels as been done.

With design suggested by Ruthger

Btw, we got feedback about the opacity of the links and they would like to have it at 0.3 instead of 0.15. I included this into this PR.

lgtm

Nice additions and changes but there are still a number of issues that needs to be addressed, namely:

Ubuntu 20.04 Chrome looks like below:

Is this how it is supposed to look, with a scroll bar?

Yes, the graph options has its own size. We would need to refactor that to fix this. But the scroll is the expected behaviour

Non-interactive mode stops when you change settings, intentional perhaps?

Mmmmh, not sure. On the other hand, being able to change settings on the graph with a graph moving can be difficult to actually see results, so I would consider this as beneficial.

I can't seem to see or locate the shortcut section of the settings panel. Was this part of this PR?

No, separate PR for shortcut panel and shortcuts

Firefox complains that the page seems to be slowing down its performance. Not sure if this is exclusive to the refactor but possibly not. Same issues except for performance hit persist over Chrome/Firefox.

I had the same warning in firefox prior to starting working on this refactoring.

Safari and chrome do work fine. Also fixed the bug on safari that was preventing displaying the filter panel (thanks to refactoring layout, was not willingly haha)

authors: RuthgerD alrapal

repo: ItJustWorksBetterTM/EiffelVis


text:
Index file for content types is ordered differently on different platforms

regarding .xp-codegen/site/content-types/index.d.ts
On windows the element in the file is ordered alphabetically
on Mac OS at least, it is ordered by some other logic.
Here is an example of a committ with no other changes than ordering, between one system and another.
https://github.com/statisticsnorway/mimir/commit/f84664cf9f10d50ac244020e8e85bd9e849c2364

I see that the commit you shared is on xp-codegen-plugin@2.1.0. We released a fix to this last week in the 2.2.0 release

@Glenruben Could you upgrade to 2.2.0, and confirm that the issue has been fixed?

Can confirm that this fixed the issue! Thank you!

source: gharchive/issue

authors: Glenruben tajakobsen

repo: ItemConsulting/xp-codegen-plugin

license: MIT

license_type: permissive

license_source: github-api


text:
[MOB-7252] sets up click handling for external/deep linking

🔹 Jira Ticket(s)

MOB-7252

✏ Description

sets up the handleEmbeddedClick function which can be called app side where a click is handled
sets up functionality for validating the URL and calling the urlHandler set up on the app side in the urlDelegate in the config

Could you add some unit tests for this?

Could you add some unit tests for this?

I will add as a fast follow on a separate PR since we are targeting testing by next wednesday.

Could you add some unit tests for this?

I will add as a fast follow on a separate PR since we are targeting testing by next wednesday.

This functionality is actually covered by ActionRunnerTests.swift. The added functionality for embedded just processes the click information and passes it to the same action runner that in-app messages use.

source: gharchive/pull-request

repo: Iterable/swift-sdk


text:
identifier “notiffication_settings” seems to be written incorrectly

It is possible that the identifier “notiffication_settings” (with two f) is not used in the app V4.8.0, as it is called “notification_settings” (with one f) in the source code of the app?

it is used, I'd rather keep it as is for now. changing the name of the key will cause issues with the current translations. the key name has no effect on anything otherwise

authors: TomTomZoe knowbody

repo: Iternio-Planning-AB/abrp-translations


text:
BUG: Submit button position not appropriate

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?

Submit button is not at proper position
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Open Source Village
Hii @Its-Aman-Yadav ,
I feel that the submit button can me positioned at centre to make it more attractive & shapes of buttons can be changed for more attractive look.
I am a contributor at GSSoC'24 & have a knowledge of HTML & CSS with which I can make your home page look more attractive .
Kindly please assign me this issue.
Add Screenshot
Screenshot (31)
I agree to the follow the project's Code of Conduct

repo: Its-Aman-Yadav/Community-Site


text:
fixed cross-compilation for Android with CUDA

CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
  Could NOT find CUDA (missing: CUDA_NVCC_EXECUTABLE CUDA_INCLUDE_DIRS
  CUDA_CUDART_LIBRARY) (Required is exact version "6.0")
Call Stack (most recent call first):
  /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindCUDA.cmake:1027 (find_package_handle_standard_args)
  /home/sandye51/Documents/Programming/build/opencv-release-master-android/OpenCVConfig.cmake:258 (find_package)
  CMakeLists.txt:38 (find_package)

-- Configuring incomplete, errors occurred!

:+1:

repo: Itseez/opencv


text:
Missing focus mode or query

400: If the request is malformed or missing required fields (e.g., no focus mode or query).
I am using the Request Body Structure test case provided in the SEARCH.md file to call search API, but I keep getting this error message {"message":"Missing focus mode or query"}. I double check the structure, and focusMode and query are not missing.

I also have this problem. Could you tell me how you solved it?

Okay, I found the reason.I use the following code to call the API, but get an error.
`import requests
定义请求的 URL 和数据
url = "http://localhost:3001/api/search"
data = {
"chatModel": {"provider": "openai", "model": "gpt-4o-mini"},
"embeddingModel": {"provider": "openai", "model": "text-embedding-3-large"},
"optimizationMode": "speed",
"focusMode": "webSearch",
"query": "你好"
}
发送 POST 请求
response = requests.post(url, data=data)Finally, I found that changingresponse = requests.post(url, data=data)toresponse = requests.post(url, json=data)` would work.

Okay, I found the reason.I use the following code to call the API, but get an error.
import requests

url = "http://localhost:3001/api/search"
data = {
    "chatModel": {"provider": "openai", "model": "gpt-4o-mini"},
    "embeddingModel": {"provider": "openai", "model": "text-embedding-3-large"},
    "optimizationMode": "speed",
    "focusMode": "webSearch",
    "query": "你好"
}

response = requests.post(url, data=data)

Finally, I found that changing response = requests.post(url, data=data) to response = requests.post(url, json=data) would work.

Hi, glad to hear that! And FYI, my solution is that I found in /src/config.ts, line 34, the getPort does not specify the environment port number provided by GCP cloud run. Thus, I changed it to export const getPort = () => process.env.PORT || loadConfig().GENERAL.PORT || 8080;, and it works.

authors: LiLinduo g-bits-zhangwh

repo: ItzCrazyKns/Perplexica


text:
fix make clang_format

does not work

done

repo: IvanVnucec/cubesat-adcs


text:
[DOCS] add code of conduct

Description
Hi there!
I recommend adding a CODE_OF_CONDUCT.md file to your repository. This file would serve as a guide for potential contributors, providing them with a clear set of expectations, guidelines, and behavior standards for participating in your project. It plays an essential role in creating a welcoming and inclusive environment for everyone involved.
I would like to work on this issue. Please assign it to me under GSSoC'23.
Thank you!
Screenshots
No response
Additional information
No response

Is this issue under GSSOC 23, if so please assign me this issue


text:
Irika team updates

Adding Irika summary and picture to the our team page

Thanks Irika!

authors: JEFworks irikas


text:
Securing Artifactory with SSL

Is there any option to secure the docker.bintray.io/jfrog/artifactory-oss image directly with SSL?
Currently I only found examples that use the opinionated nginx-artifactory-pro image what yields some problems:
Imagine a Swarm cluster that provides some CI services like Artifactory, Jenkins and so on. Having all these services inside the swarm, often one central API/reverse proxy is desired (like Traefik) so that traffic can be routed to the distinct services without having to bring up a dedicated poxy for each service.
Also, having multiple proxies running in the swarm but port 443 being only bindable once, so kind of port mapping needs to be done in front of the Swarm cluster what is also no real good.
There is also a security concern, as traffic between Artifactory and the reverse proxy itself is not encrypted.

@holgerstolzenberg - you can use the docker.bintray.io/jfrog/nginx-artifactory-pro or any standard nginx image to provide you with the SSL.
You can add Artifactory OSS to your existing load balancer in a cluster of services.
If you insist, you can build a new Docker image that has Artifactory and Nginx together (not recommended) to avoid having them talk on the host network, although I think this is an overkill.
I hope this gives you an idea...

Thanks for the answer, but the idea is already clear. In our scenario we use traefik.io to reverse proxy services within a Swarm cluster. One of these services is Artifactory. It works without any problems. The problematic point is that SSL is terminated at the Traefik reverse proxy, but communication between Traefik <-> Artifactory is still unencrypted.
Using docker.bintray.io/jfrog/nginx-artifactory-pro will not solve the problem, as communication between the Nginx <-> Artifactory will be unencrypted.
I know that overlay networks can be encrypted. Looking at https://docs.docker.com/engine/userguide/networking/overlay-security-model/ you can see that:

You can also encrypt data exchanged between containers on different nodes on the overlay network.

In my understanding, in a hypothetic situation, having Nginx/Traefik and Artifactory running on the same host, communication between them is unencrypted and might be sniffed.
For me, an possible solution could be to be able to enable the SSL connector of the Tomcat via env properties (and disable HTTP connector likewise).
I do not know the deeper architecture of Artifactory. Looking at it from a wider perspective entering the container world, it looks like migrating Artifactory to a standalone app with a SSL secured embedded servlet container is a reasonable choice (Spring Boot).

Look at https://www.jfrog.com/jira/browse/RTFACT-7201. I think this is what you are looking for, but it will require you to build a new Docker image based on docker.bintray.io/jfrog/artifactory-oss that does the needed modifications to server.xml.
I'm closing this issue. Feel free to open a JIRA issue if you think more is required.

authors: eldada holgerstolzenberg

repo: JFrogDev/artifactory-docker-examples

license_source: bigquery


text:
Access to 'Reader View' within app

Hi,
It would be great to also have access to the Reader view and other views as well, potentially within the app that can provide a good reading experience without going into the browser.
Thanks!

What do you mean with reader mode? Is that a Linkding feature?

I'm checking it and I don't have that option 🤨

Yes, I'm using latest tag. I will work on this when it's available for everyone.


text:
Add support for serializing and deserializing data stored in LabView Variant Attributes.

Variant Attributes can be used as key/value stores (hash tables) in LabVIEW.
Since attributes can be defined at runtime, they are also useful for constructing
nested data structures for which the data type is not known at compile time.
This commit adds support for serializing variant attributes to JSON strings, and
for deserializing JSON strings into LabView variant data with attributes. Arbitrary
JSON strings can be manipulated at run-time using a combination of LabView arrays
of variants and variant attributes.
Details:
A JSON string is either an object or an array comprising six kinds of values:
strings, numbers, objects, arrays true/false, and null. Most of the data handling
derives from the existing JKI JSON parser, the main exception being the use of
variant attributes instead of compile-time defined clusters for JSON objects.
Scalars
Scalar types (strings, numbers, true/false) are represented as data of the
appropriate type cast to variants. Numeric types are represented by LabView
"extended" numeric type, which is at least 64 bits on all platforms.
Null
Null (also a scalar) is represented by a void (default) variant cast to a variant.
Compare with empty object below.
Arrays
Arrays are represented as arrays of variants cast to a (scalar) variant. While
LabView requires all elements of an array to have the same data type, JSON does
not: a string like [true, "Hamlet", 3.14159] is a legal JSON array. Thus the
library deserializes JSON arrays to an array of variants, which can then be cast as
necessary on a per-element basis. (LabView variants are data-type aware so you
can inspect the data type of each element inside a loop.)
Objects
JSON objects are respresented by the library by a void (default) variant with
attributes. A void variant without any attributes defined is the empty object
but there is some ambiguity in how the library handles empty objects (see issues).
A void variant containing one or more attributes will be serialized as a JSON
object in which the JSON name is the attribute name and the JSON value the
attribute value. Objects can be nested by passing the appopriate input to Set
Variant Attribute function.
To extract data from variants with attributes, use the Get Variant Attribute
function in conjunection with Variant to Data. (Cast JSON arrays to an array
of variants if data type is not known as compile time). Nested objects can be
extracted with repeated application of the appropriate functions.
Issues:

LabView does not have a native null data type. This commit maintains the
behavior of the JKI JSON library in which JSON are represented in slightly
inconsistent ways, as follows.

On serialization, a default (void) variant generates a null in the output
JSON string. However, deserializing a null value returns a default (void)
variant cast to a variant (e.g. it is a nested structure.)
{"key":null}  returns a void variant cast to variant
This allows the deserializer to return a default (void) variant for an
empty object:
{"key": {} }  returns a void variant
From the point of view of usign variant attributes, the deserializer's
behavior is "correct", in that it returns a void variant with zero attributes,
but I did not want to change the behavior of the serializer without discussion.

I am making use of "Get Type Information.vi" found in LabView 2015 vi.lib. It
may be necessary to replace this function on earlier versions of LabView. (The
rest of the library uses a deprecated vi.lib function.)

Current the library is pretty difficult to use, in part because there
is no visibility into the deeper levels of the LabView variant structures on
the front panel. This will be addressed with "Generic JSON Data" class I'm
writing that provides object construction, searching etc.

Variant attributes won't be supported for now in the official branch.

authors: robertbcalhoun tmaila

repo: JKISoftware/JKI-JSON-Serialization


text:
Set Parameters for Nodes Rather than Inputs and Outputs

Is there a way to set a parameter for a node that is not an input or an output? For example say I wanted to scale and shift my input value linearly in the form y = mx + b. My input is x and my output is y and m (slope) and b (y-intercept) would be parameters of the node. Is there a way to have a user set these parameters already or do nodes only have inputs and outputs?

I hope I understand you correctly.
If you are absolutely sure that 'm' and 'b' will never need modifying, you can simply hard-code them:
def run(self):
   m = 2
   b = 1
   self._y(m*self._x + b)

Usually, it is helpful to supply the values for 'm' and 'b' via inputs that have default values. That way you don't need to do anything to get the same behavior but can simply change the values for each instance individually:
class ScaleAndShift(Node):
   Input('x', float)
   Input('m', float, default=2)
   Input('b', float, default=1)
   Output('y', float)

   def run():
      self._y(self._m*self._x + self._b)

I hope this answers your question.
PS:
In an earlier prototype I used something called 'parameters' - basically 'inputs' that could only be edited by the user directly. No connections to other nodes were possible. I realized that they provide nothing that 'inputs' cannot do already so I removed them.

authors: JLuebben rhingo

repo: JLuebben/Floppy


text:
🛑 jm26.net is down

In 5ce1897, jm26.net (https://jm26.net/status.txt) was down:

HTTP code: 502
Response time: 422 ms

Resolved: jm26.net is back up in ebc2ede after 10 minutes.


text:
Update PDF Documentation

To simplify the PDF documentation please create a singular PDF instead of many PDF files that are confusing to use.

PDF created

repo: JNPRAutomate/JNPRAutomateDemo-Class


text:
made ratingReviews model/controller/routes, fix error handling, and m…

made ratingReviews model/controller/routes,
fix error handling,
made associations
move the database connection outside errors

made ratingReviews model/controller/routes,
fix error handling,
made associations
move the database connection outside errors


text:
Add optional unqiue string in attachment name

Situation
My notes follow a rule:

Have a page (.md) for notes
Avoid having a page with the same name as a folder, especially on the same level, instead create an index.md in the folder.

I have these rules since they make it navigate in a file explorer (reduces list size by half). And also for publishing the notes as a website.
Problem
The current plugin format does not consider the route of the file (i.e. folder1/folder2/folder3).
It only considers the fileName (attachmentType remains the same, and indexNumber may also be duplicated easily, so let's ignore them).
Due to my rule 2, all attachments in index.md files will be named the same - index-image-indexNumber.xxx.
Solution
I know that the problem is specific to my situation,  and I think it's fine if the whole route is not in the attachment name (which would also solve the problem - but would make file names too big).
A simpler solution would be to have a unique identifier (by some logic - maybe hash the route) at the end of the filename.
Storing "time" as the unique string doesn't help, since I also do linting (which edits multiple files quickly - at almost the same time).

Thanks for creating pull request! Now it's added in 2.1.3


text:
🛑 Glitch is down

In 9b7b979, Glitch ($GLITCH) was down:

HTTP code: 503
Response time: 316 ms

Resolved: Glitch is back up in af61277 after 37 minutes.

repo: JYFUX/upptime


text:
Add frequently used citation styles

@mohit038 all the .csl styles are from https://github.com/citation-style-language/styles ?
@koppor since you were involved in https://github.com/citation-style-language/styles/issues/2372 , do you know if it is enough to add a README.md with an explicit mention and link to the CSL project to fulfill https://github.com/citation-style-language/styles#licensing ?

Todo:

[ ] Extract setting handling to new file / class
[ ] Refactor component state to use citation style id/value

repo: JabRef/JabRef-Word-Addin


text:
Blog entries should have colors alternating

Currently, two consecutive blog entries have to be configured within them to have colors alternating. This should be done by the template.
bg and color should be set by the template
Examples: https://github.com/JabRef/blog.jabref.org/blob/gh-pages/_posts/2019-08-27-JabCon-Release.md and https://github.com/JabRef/blog.jabref.org/blob/gh-pages/_posts/2019-10-03-Hacktoberfest.md

@koppor I can work on it. The coloring sequence is disturbed from this " 2017-04-17-JabRef4-0-beta.md " post.

The Jekyll template has to be fixed so that bg and color is not needed on any post anymore!

Starting point: https://github.com/JabRef/blog.jabref.org/blob/gh-pages/_layouts/default.html

Not relevant any more

authors: koppor sumitkharche


text:
[app] Résolution des adresses de sites de vidéos

Lorsqu'on rentre une URL Youtube, l'application résout l'adresse pour n'afficher que le player Youtube.
Les adresses suivantes :

https://www.youtube.com/watch?v=L6ywt7VnEw8
https://youtu.be/L6ywt7VnEw8

seront résolues en https://www.youtube.com/embed/L6ywt7VnEw8
--
Doit aussi fonctionner avec la fonctionnalité des playlists.
Les adresses de playlist suivantes :

https://www.youtube.com/watch?v=y2wBa1wEiKg&list=PL0uZKL1TuNkrA6hL-KhV4p9wPUa1dVJOr
https://youtu.be/y2wBa1wEiKg?list=PL0uZKL1TuNkrA6hL-KhV4p9wPUa1dVJOr

seront résolues en https://www.youtube.com/embed/y2wBa1wEiKg?list=PL0uZKL1TuNkrA6hL-KhV4p9wPUa1dVJOr

Youtube
Vimeo
Dailymotion
Twitch (VODs et streams)
Hitbox (VODs et streams)

Support for Youtube and Twitch in d610619907592dc0f711e9a28aebbbc266a64cc3


text:
34 chat completions

Closes #34

just needs an integration test for the chat completions client where we stub out the http requests and then were good to go

repo: JackMatthewRimmer/rust-rag-toolchain


text:
🛑 US Central A (HS) is down

In b92fb2f, US Central A (HS) (http://a.us-central.servers.jackz.me) was down:

HTTP code: 0
Response time: 0 ms

Resolved: US Central A (HS) is back up in ac8cfdc.

repo: Jackzmc/upptime


text:
Support for class inheritance?

When testing with this file it looks like the value of person.age is zero. Is this a bug, or missing feature?
// The entry file of your WebAssembly module.

import { JSON } from "json-as/assembly";

// @ts-ignore
@json
class Aged {
  age: i32;
}

// @ts-ignore
@json
class Player extends Aged {
  // age: i32;
  firstName: string;
  lastName: string;
}

// const stringified = JSON.stringify<Player>(data);

export function add(json: string, b: i32): i32 {
  const person = JSON.parse<Player>(json);
  return person.age + b + person.firstName.length;
}

This is a missing feature due to it not being implemented in the transform. Parent type data needs to be cast to the Child data and reflected in the child methods.
I'll put this on my todo list.
Thank  you for bringing this up!

Hi @JairusSW , the example you posted doesn't work:
FAILURE TypeError: (intermediate value)(intermediate value)(intermediate value) is not iterable (cannot read property undefined)
    at AsJSONTransform.visitClassDeclaration (node_modules/json-as/transform/lib/index.js:71:47)

Thanks!

It works for me, but it looks like I didn't have an undefined check there.

@mariusa, can you send me some example code?

Hi, it's exactly the code you posted above:
import { wasi_console } from "@assemblyscript/wasi-shim/assembly/wasi_console"
import { u128 } from "as-bignum/assembly"
import {
    JSON
} from "json-as/assembly"

// @ts-ignore
@json
class Vec3 {
    x: f32 = 3.4;
    y: f32 = 1.2;
    z: f32 = 8.3;
}

// @ts-ignore
@json
class Stats extends Vec3 {
    wins: u128
    loss: u128
}

// @ts-ignore
@json
class Player {
    firstName: string
    lastName: string
    lastActive: i32[]
    age: i32
    isVerified: boolean
    stats: Stats
}

const player: Player = {
    firstName: "Emmet",
    lastName: "West",
    lastActive: [8, 27, 2022],
    age: 23,
    isVerified: true,
    stats: {
        wins: u128.fromString("443"),
        loss: u128.fromString("693")
    }
}

const serializedPlayer = JSON.stringify<Player>(player)
wasi_console.log("Serialized Player: " + serializedPlayer)
const deserializedPlayer = JSON.parse<Player>(serializedPlayer)
wasi_console.log("Deserialized Player: " + JSON.stringify(deserializedPlayer))

gives
FAILURE TypeError: (intermediate value)(intermediate value)(intermediate value) is not iterable (cannot read property undefined)
    at AsJSONTransform.visitClassDeclaration (file:///my-project/node_modules/json-as/transform/lib/index.js:71:47)
    at AsJSONTransform._visit (/my-project/node_modules/visitor-as/src/base.ts:269:14)
    at AsJSONTransform._visit (/my-project/node_modules/visitor-as/src/path.ts:13:11)
    at AsJSONTransform.visit (/my-project/node_modules/visitor-as/src/visitor.ts:34:12)
    at TopLevelDecorator.visitDecoratorNode (/my-project/node_modules/visitor-as/src/decorator.ts:39:20)
    at TopLevelDecorator._visit (/my-project/node_modules/visitor-as/src/base.ts:316:14)
    at TopLevelDecorator._visit (/my-project/node_modules/visitor-as/src/path.ts:13:11)
    at TopLevelDecorator.visit (/my-project/node_modules/visitor-as/src/visitor.ts:34:12)
    at <anonymous> (/my-project/node_modules/visitor-as/src/visitor.ts:21:31)
    at Array.map (<anonymous>)

This error is solved in current versions

authors: JairusSW dselman mariusa

repo: JairusSW/as-json


text:
File upload triggered when hitting the enter key on any input text

How to suppress the file upload window from showing when hitting enter from any input text inside the form?

Just realized setting buttonType='button' fixed this issue

repo: JakeHartnell/react-images-upload


text:
Explain todos

It's just a reminder, since I visit this repo three-four times a week and still see the todos. It's very interesting to me. Thanks

This project is not currently being worked on and its code is not even in a usable state. It's only on GitHub because I was playing around and wanted to show a single person the code. I don't have any plans to continue working on this project at this time.

@tonyshkurenko You could fork this project and create a library out of it.

I ain't sure I'm able to do that :)

@tonyshkurenko Sure you can do that. And even if the library never gets finished you'll learn a lot from it. I guess @JakeWharton csn confirm that ;-) When I started my first open source library it helped a lot looking at best practices and comparing code style and API style to other common libraries. Jake's libraries are just perfect so don't hesitate to look at his code and learn from it. That's the whole purpose of open source

repo: JakeWharton/DrawerBehavior


text:
upgrade: operational migration to pydantic v2

builds upon #4, all existing tests (excepting tests/test_duckdb/*) passing after upgrade to pydantic==2.4.2, polars==0.19.11
Closes #11
Closes #28
Closes #26
...possibly closes others
Summary

(breaking change) recover legacy ValidationError from pydantic v1 to allow for multiple error reporting, collect data frame validation errors in this object, rename as DataFrameValidationError to distinguish from errors raised by pydantic directly.

users will need to update exception catching on data frame validation

subclass pydantic.fields.FieldInfo to accommodate patito-specific field attributes (constraints, derived_from, dtype, unique)
update patito.Model._schema_properties to append patito-specific field attributes to the field property dictionaries to pydantic.BaseModel.model_json_schema

avoids serialization errors raised when passing patito-specific fields via json_schema_extra

(breaking change?) separation of concepts of required and nullable. nullable now refers to columns that allow pl.Null as a valid entry. required (pydantic-side) refers to columns that do not have a default value, and therefore must be passed to the BaseModel constructor.
fix polars.collect bug (see #24)

TODO

[ ] refactor directory structure for patito.pydantic

patito
+-- src
|  +-- pydantic
|  |  +-- main.py (`BaseModel`)
|  |  +-- fields.py (`FieldInfo`, `Field`)

[ ] updates where necessary to documentation and readme

And I'm sure there are other issues introduced by these changes, and bugs that the existing test suite does not yet catch. But hopefully this serves as a template for discussion and new test collection and can help move the ball forward on getting this package onto pydantic2. Feedback very welcome.

I'll build this one locally and see if it will fix the other bugs Patito 0.50 still has

They were also working on v2 here: https://github.com/JakobGM/patito/tree/jakobgm%2Fpatito-v2

I'll build this one locally and see if it will fix the other bugs Patito 0.50 still has

Anxious to hear how it goes

@brendancooley nice work! The FieldInfo class nicely fixes the issue with properties being last after the class method, I solved a bit a different with v1 https://github.com/JakobGM/patito/pull/20, Perhaps you can grab my test from there and include it in your pr. I already checked they test also passes with your changes.
One thing that still will be broken is the examples creation, you need to include this fix https://github.com/JakobGM/patito/pull/20 and then build on top of it since now a type which is Optional[str] will have the parameter minimum behind a list in the anyOf key.

@brendancooley nice work! The FieldInfo class nicely fixes the issue with properties being lost after any class method, I solved a bit a different with v1 #20. Perhaps you can grab my test from there and include it in your pr. I already checked the test also passes with your changes.
One thing that still will be broken is the examples creation, you need to include this fix #20 and then build on top of it since now a type which is Optional[str] will have the parameter minimum behind a list in the anyOf key.
I will run it tomorrow on our production repo to see if anything breaks : ) (possibly in the examples creation it will)

happy to include the test. did you mean to reference a different issue/pr in your second comment? not clear on how #20 helps with example string generation but perhaps I am missing something.

@brendancooley nice work! The FieldInfo class nicely fixes the issue with properties being lost after any class method, I solved a bit a different with v1 #20. Perhaps you can grab my test from there and include it in your pr. I already checked the test also passes with your changes.
One thing that still will be broken is the examples creation, you need to include this fix #20 and then build on top of it since now a type which is Optional[str] will have the parameter minimum behind a list in the anyOf key.
I will run it tomorrow on our production repo to see if anything breaks : ) (possibly in the examples creation it will)

happy to include the test. did you mean to reference a different issue/pr in your second comment? not clear on how #20 helps with example string generation but perhaps I am missing something.

#20 is a fix regarding, creating proper examples with numerical values. I meant just taking that fix directly into pydantic v2 won't work. I saw that grabbing the minimum field is now nested if you have a field that is optional

@brendancooley tried it on our repo and tests, I am also getting this now static type hint error:
Expression of type "FieldInfo" cannot be assigned to declared type "int"
  "FieldInfo" is incompatible with "int"

on this code:
class Test(pt.Model):
    test: int= pt.Field(constraints=pl.struct("a", "b").is_unique())

Also nullable columns are not working, mre:
class Test(pt.Model):
    foo: str|None = pt.Field(dtype=pl.Utf8)

print(Test.nullable_columns)
set()

Thanks @ion-elgreco, I'll add these tests to the PR and start hacking at them tomorrow. Have not looked much into structs but it would be nice if we had more tests for those.

Thanks @ion-elgreco, I'll add these tests to the PR and start hacking at them tomorrow. Have not looked much into structs but it would be nice if we had more tests for those.

This example where I am using a struct is just a simple trick to do multiple column uniqueness.

Also nullable columns are not working, mre:
class Test(pt.Model):
    foo: str|None = pt.Field(dtype=pl.Utf8)

print(Test.nullable_columns)
set()

Result should be: {'foo'}

@ion-elgreco should be addressed by https://github.com/JakobGM/patito/pull/32/commits/e2bf0d7351ca8750affcbae8f65ce0e48357dcd5

https://github.com/JakobGM/patito/pull/32/commits/017c59b2373705059b951b6a22f8f6dd787c851a also adds some sanity checking that the annotated types match the allowable polars types specified in Field.dtype

@brendancooley tried it on our repo and tests, I am also getting this now static type hint error:
Expression of type "FieldInfo" cannot be assigned to declared type "int"
  "FieldInfo" is incompatible with "int"

on this code:
class Test(pt.Model):
    test: int= pt.Field(constraints=pl.struct("a", "b").is_unique())

yes I can replicate these in vscode if I enable
{
  "python.analysis.typeCheckingMode": "basic"
}

in settings.json. Looking into it.

@brendancooley tried it on our repo and tests, I am also getting this now static type hint error:
Expression of type "FieldInfo" cannot be assigned to declared type "int"
  "FieldInfo" is incompatible with "int"

on this code:
class Test(pt.Model):
    test: int= pt.Field(constraints=pl.struct("a", "b").is_unique())

This should be handled by https://github.com/JakobGM/patito/pull/32/commits/161300b80c1f898d7246b46bd0a918e6ab818426

@brendancooley nice work! The FieldInfo class nicely fixes the issue with properties being lost after any class method, I solved a bit a different with v1 #20. Perhaps you can grab my test from there and include it in your pr. I already checked the test also passes with your changes.
One thing that still will be broken is the examples creation, you need to include this fix #20 and then build on top of it since now a type which is Optional[str] will have the parameter minimum behind a list in the anyOf key.
I will run it tomorrow on our production repo to see if anything breaks : ) (possibly in the examples creation it will)

happy to include the test. did you mean to reference a different issue/pr in your second comment? not clear on how #20 helps with example string generation but perhaps I am missing something.

#20 is a fix regarding, creating proper examples with numerical values. I meant just taking that fix directly into pydantic v2 won't work. I saw that grabbing the minimum field is now nested if you have a field that is optional

Yes this makes sense. Let me know if https://github.com/JakobGM/patito/pull/32/commits/9e132bc49baebaf3cf874c3469e61c811df88b74 fixes the issue.

I see more bugs at the moment with the types it's checking for and the examples it's creating:
examples ignores the dtype when it's an optional field, see test below:
class Test(pt.Model):
    foo: int | None = pt.Field(dtype=pl.UInt32)

assert pl.DataFrame(schema={'foo':pl.UInt32}).schema == Test.examples().schema

Also, this seems executes while it shouldn't:
class Test(pt.Model):
    foo: str | None = pt.Field(dtype=pl.UInt32)

Lastly with datetimes the mapping is not correct:
class Test(pt.Model):
    date: datetime = pt.Field(dtype=pl.Datetime(time_unit="us"))

`ValueError: Invalid dtype Date for column 'date'. Check that specified dtype is allowable for the given type annotations.`

🐞👟 @ion-elgreco keep em coming, hopefully https://github.com/JakobGM/patito/pull/32/commits/93e171e3424f39269ccabbc6b31e00219ed77bd0 addresses with better logic for column nullability

@brendancooley nice, all my original unit-tests are running now : )

Also very nice to see this issue will also get resolved now: https://github.com/JakobGM/patito/issues/11. I think you can add all these issues I've mentioned to the - closes in the pr description 🕺

Actually found a couple bugs:
.examples() does not work when you have this class:
class Test(pt.Model):
    foo: list[str] | None  = pt.Field(dtype=pl.List(pl.Utf8))

Test.examples({"foo":[['test']]})

# results into
TypeError: argument of type 'NoneType' is not iterable

This is also possible, but shouldn't be
class Test(pt.Model):
    foo: list[str] | None  = pt.Field(dtype=pl.Utf8)

Also very nice to see this issue will also get resolved now: #11. I think you can add all these issues I've mentioned to the - closes in the pr description 🕺. The new version will be huge 😄
One suggestion on the dtype mismatches, it could be rewritten to this to clarify what the current data schema dtypes is and what the expected model dtype is. The data field dtype Float32 does not match the model schema field dtype: int | None (type=type_error.columndtype)
The old one does not immediately give away what the expected data dtype should be.
foo
  Polars dtype Float32 does not match model field type. (type=type_error.columndtype)

Like this idea, cleaned up the messaging a bit on https://github.com/JakobGM/patito/pull/32/commits/e9dbca6b0d6986fc3b76bda074e26d099c291b1e
Should see errors messages like e.g.
"Invalid dtype UInt32 for column 'foo'. Allowable polars dtypes for Union[str, NoneType] are: Utf8."

@thomasaarholt also dropped the classproperties set via the ModelMetaclass. Definitely cleaner than the metaclass+classvar formulation. Went back and forth a bit but decided to adopt polars' classproperty decorator to try to avoid getting caught up in python debates about whether to preserve this functionality: https://stackoverflow.com/questions/76249636/class-properties-in-python-3-11
Test suite does fine with this but @ion-elgreco lmk if you run into issues.

@brendancooley I got lost a bit, what is the different way of approach class properties solving here?

@brendancooley I got lost a bit, what is the different way of approach class properties solving here?

The original implementation used a combination of ClassVar and patito.pydantic.ModelMetaclass to set class properties such as Model.columns. Here's the original note:
    # -- Class properties set by model metaclass --
    # This weird combination of a MetaClass + type annotation
    # in order to make the following work simultaneously:
    #     1. Make these dynamically constructed properties of the class.
    #     2. Have the correct type information for type checkers.
    #     3. Allow sphinx-autodoc to construct correct documentation.
    #     4. Be compatible with python 3.7.
    # Once we drop support for python 3.7, we can replace all of this with just a simple
    # combination of @property and @classmethod.

Since we're on python^3.8 now I think pattern can be safely deprecated. The natural way to do this is to use
class Model(BaseModel):

    @classmethod
    @property
    def columns(cls):
        ...

however, it appears python does not plan on supporting this pattern in the future.
In our case, it's extremely useful to be able to mark classproperties this way, so I adopted polars' custom @classproperty implementation in order for us to be able to replace the dual @classmethod, @property syntax with
class Model(BaseModel):

    @classproperty
    def columns(cls):
        ...

Actually found a couple bugs:
.examples() does not work when you have this class:
class Test(pt.Model):
    foo: list[str] | None  = pt.Field(dtype=pl.List(pl.Utf8))

Test.examples({"foo":[['test']]})

# results into
TypeError: argument of type 'NoneType' is not iterable

This is also possible, but shouldn't be since the type annotation doesn't match the pt.Field dtype. It seems for any list type annotation there is no corresponding check with the patito dtype, I think you need do something with recursion here to check all of these nested complex types. Ideally you should be able to provide complex nested dtypes like: list[list[list[datetime]]]. Then this would also work later with pl.Stuct #30 and then you can create really nice validation models.
class Test(pt.Model):
    foo: list[str] | None  = pt.Field(dtype=pl.Utf8)

I also noticed, the pt.Field docs are missing at the moment: Field.__doc__ = FieldDoc.__doc__ this does not seem to work properly. Also, I think it would make more sense if we can see the parameters in the function definition, otherwise there is no functioning auto completion and it's unclear (outside of reading the docs) which parameters are valid or not.
If you need any help, just let me know ;)

I think this is fixed by https://github.com/JakobGM/patito/pull/32/commits/db44aa344edfa51fec9a9bc114a187b5e780f081
Field.__doc__ works ok for me? Do you have an example of where it's not appearing? I went ahead and put the patito-custom fields in the Field signature, but left off the pydantic was. Idea being that we want this signature to be robust to possible changes in pydantic's Field signature. Do we think version 2 is stable enough for us to copy their args over directly? I haven't followed closely followed the roadmap over there.

@brendancooley I got lost a bit, what is the different way of approach class properties solving here?

The original implementation used a combination of ClassVar and patito.pydantic.ModelMetaclass to set class properties such as Model.columns. Here's the original note:
    # -- Class properties set by model metaclass --
    # This weird combination of a MetaClass + type annotation
    # in order to make the following work simultaneously:
    #     1. Make these dynamically constructed properties of the class.
    #     2. Have the correct type information for type checkers.
    #     3. Allow sphinx-autodoc to construct correct documentation.
    #     4. Be compatible with python 3.7.
    # Once we drop support for python 3.7, we can replace all of this with just a simple
    # combination of @property and @classmethod.

Since we're on python^3.8 now I think pattern can be safely deprecated. The natural way to do this is to use
class Model(BaseModel):

    @classmethod
    @property
    def columns(cls):
        ...

however, it appears python does not plan on supporting this pattern in the future.
In our case, it's extremely useful to be able to mark classproperties this way, so I adopted polars' custom @classproperty implementation in order for us to be able to replace the dual @classmethod, @property syntax with
class Model(BaseModel):

    @classproperty
    def columns(cls):
        ...

and not worry about what python does with @classmethod and @property in future versions

That makes sense! Thanks for explaining, wasn't aware of these differences.

Actually found a couple bugs:
.examples() does not work when you have this class:
class Test(pt.Model):
    foo: list[str] | None  = pt.Field(dtype=pl.List(pl.Utf8))

Test.examples({"foo":[['test']]})

# results into
TypeError: argument of type 'NoneType' is not iterable

This is also possible, but shouldn't be since the type annotation doesn't match the pt.Field dtype. It seems for any list type annotation there is no corresponding check with the patito dtype, I think you need do something with recursion here to check all of these nested complex types. Ideally you should be able to provide complex nested dtypes like: list[list[list[datetime]]]. Then this would also work later with pl.Stuct #30 and then you can create really nice validation models.
class Test(pt.Model):
    foo: list[str] | None  = pt.Field(dtype=pl.Utf8)

I also noticed, the pt.Field docs are missing at the moment: Field.__doc__ = FieldDoc.__doc__ this does not seem to work properly. Also, I think it would make more sense if we can see the parameters in the function definition, otherwise there is no functioning auto completion and it's unclear (outside of reading the docs) which parameters are valid or not.
If you need any help, just let me know ;)

I think the examples generation issue is fixed by db44aa3
Field.__doc__ works ok for me? Do you have an example of where it's not appearing? I went ahead and put the patito-custom fields in the Field signature, but left off the pydantic was. Idea being that we want this signature to be robust to possible changes in pydantic's Field signature. Do we think version 2 is stable enough for us to copy their args over directly? I haven't followed closely followed the roadmap over there.

I don't have a reproducible example for that but it was when using Pyright and Pylance in VS code, the Field signature was empty. I checked your commit, but I don't think you will see the pydantic parameters now, such as (ge, le, lt, unique, pattern etc.). Ideally these are also visible in signature,

I don't have a reproducible example for that but it was when using Pyright and Pylance in VS code, the Field signature was empty. I checked your commit, but I don't think you will see the pydantic parameters now, such as (ge, le, lt, unique, pattern etc.). Ideally these are also visible in signature,

Thinking on the best way to accomplish this. Would be nice if we could develop a nice framework for extending FieldInfo (and updating the signature for Field) with arbitrary user extensions.

@brendancooley @thomasaarholt What is still required to push this over the edge?
I foresee I have more time next couple weeks to help here so let me know.

@brendancooley @thomasaarholt What is still required to push this over the edge?
I foresee I have more time next couple weeks to help here so let me know.

Do we want to continue explicit duckdb support? @ion-elgreco maybe take a pass at this and see if it's easy to get the tests to pass again? If not, delete or deprecate existing code. fwiw I've been using duckdb to work with patito-modeled tables and haven't felt that explicit support is necessary.
There are still a few typing pain points, mainly pydantic.field. I'm inclined to leave this as is for now but open to suggestions for better usability.
Refactor directory structure as described above (separate Model/Field) to better mirror pydantic internal structure
Updated readme and documentation where sparse. @thomasaarholt does anything need to be done explicitly to keep the readthedocs page up to date? https://patito.readthedocs.io/en/latest/index.html

@brendancooley I think patito should only focus on Polars for now, I doubt many people use it for the DuckDB functionality.

I think we should drop duckdb support too :)
@brendancooley could you clarify for me how users can extend their requirements using the new Field/FieldInfo? I'm a bit hesitant to introduce something that doesn't get a static docstring like Field does currently. Doesn't the Field(constraints=[<some polars expressions>]) already let one add custom column requirements?

Currently, arguments not explicitly enumerated in pydantic's Field factory get thrown into json_schema_extra. This is an issue first and foremost because the feature is scheduled for deprecation.

Actually, it's the extra argument that is being deprecated,  in favour json_schema_extra json_schema_extra :)

My suggestion is going to be to use this approach of passing them from the patito Field into the pydantic Field, but I'm thinking through your comments now. I'm currently writing a longer post with a suggestion. Wanted to keep conversation going though, so wrote the above first.

This is the reason polars-serialization suddenly started throwing errors in pydantic btw. I think their changes made sense, but were unfortuante for us. https://github.com/pydantic/pydantic/pull/7625

So, both your and jakob/mine implementations currently go via the pydantic json interface (model_json_schema) in order to do a lot of functionality enabled by patito. I propose that instead, we use the BaseModel.model_fields interface, which exposes the fields information as a FieldInfo.
This means that we don't try to serialize any types, and can use pt.Field in the approach I commented above.
We would still under the hood be passing non-jsonable content to json_schema_extra, but while those arguments are intended to be json-serializable, I don't think they would try to serialize them unless explicitly called for.
I'm working in a notebook right now, going to try to at least share my approach tonight.

@brendancooley I remember @thomasaarholt created an upstream issue at Polars to make expressions serializable. I don't think this has been picked up yet.
I could take a look and see if I can work on that. I've been dangling with Rust myself in delta-rs and some plugins, so perhaps a fun challenge to build some rust code in Polars ^^

Actually nvm, it's already possible it seems :): https://github.com/pola-rs/polars/issues/12172

Hehe, since creating that issue, I've learnt two additional things:

Polars datatypes aren't (yet) serializable
We still need some mechanism to provide a fallback serializing mechanism in pydantic to deserialize into a serializable dict and then re-serialize using pydantic. The issues are a) pydantic doesn't know about .write_json(), and b) can't just concatenate two json strings directly.

To clarify on the second point, if we want to keep the JSON-approach, there are two places we might want the fallback mechanism to support serializing polars objects:
import polars as pl
from pydantic import BaseModel, Field

class Foo(BaseModel):
    type_example: pl.Int64 # here as a type hint
    extra_example: int = Field(json_schema_extra={"expression_example": pl.col("foo")}) # here as an extra

Foo.model_json_schema()

For the type hint, we would either have to:

add a field_serializer (which I actually can't manage to get work), but then we would have to add one for every column of a given name.
subclass all types we want to work with, and add a __get_pydantic_core_schema__ (example here).
add support in polars for __get_pydantic_core_schema__ on the classes we want pydantic to serialize.

For extras example, I think we can only achieve it with points 2 or 3.

I just want to add - I find the pydantic serialization documentation really complicated, and I'm struggling quite a bit with implementing it on a subclass of pl.Float64. My thoughts in the previous post might be wrong, and I'd be very happy to be corrected.

@thomasaarholt Catching up and checking my understanding...if we want to pass and store patito-specific field attributes via pydantic's json_schema_extra, we need to either:

remove all references to model_json_schema on the patito side and warn users that this is not a supported attribute for patito models (or possibly implement our own schema representation) OR
support serialization of polars expressions and dtypes, either by implementing pydantic's field_serializer or by getting polars to support it natively

On the question of deserialization...suppose we can serialize dtypes and expressions, do we need to be able to go backward from json -> python object in order for this to approach to work as well? Is this supported by polars?
Could we use the fallback kwarg in pydantic's to_jsonable_python to pass serialization instructions for these? We'd need to allow this keyword to be passed around during schema construction on the pydantic side but maybe that's more flexible then working with the field_serializer approach.

Also @thomasaarholt if your notebook scratch work is able to be shared I'd be happy to take a look and try to get up to speed on your approach.

Yes! I've just gone over it again, here it is: https://gist.github.com/thomasaarholt/c04ae8ad503a1476e5282e7098eeb1f7
I've called the result for each column a ColumnInfo class. I just needed a name that didn't have Field in it, cause I was going a little crazy 😅 .

Catching up and checking my understanding...if we want to pass and store patito-specific field attributes via pydantic's json_schema_extra, we need to either:

remove all references to model_json_schema on the patito side and warn users that this is not a supported attribute for patito models (or possibly implement our own schema representation) OR
support serialization of polars expressions and dtypes, either by implementing pydantic's field_serializer or by getting polars to support it natively

Yep! But on 2, field_serializer is not the way to go, it was just me trying to make pydantic somehow serialize a polars type. (I didn't manage it)
I don't think we need patito models to be json serializable. At least, I haven't been doing that, though I guess it might be nice to be able to save the patito schema as a json? In that case we could just add our own to_json and from_json methods. We can just convert a pl.Float64 to a "PolarsFloat64" string via a simple mapping, and then convert to and from like that.
I see that polars has added Expr.from_json, so that can read back in the result of Expr.write_json. We can probably use exactly these methods.

@brendancooley I honestly don't think this is a common pattern. You can do nearly anything with the Polars API or you use a plugin.

yeah I may just not be polars savvy enough to do this the "right" way. do you have a suggestion for how to implement the above expression in pure polars?

@brendancooley I can take a look if you have some sample data

@brendancooley I can take a look if you have some sample data

@ion-elgreco sure, how about this
from typing import Dict
from datetime import datetime
import pytz

import polars as pl

def convert_time_zone(struct: Dict) -> datetime:
    if struct["timezone_id"] is None:
        return None
    return (
        struct["datetime_utc"]
        .astimezone(pytz.timezone(struct["timezone_id"]))
        .replace(tzinfo=None)
    )

df = pl.DataFrame({"datetime_utc": [datetime.now(), datetime.now()], "timezone_id": ["America/New_York", None]})
df = df.with_columns(pl.col("datetime_utc").cast(pl.Datetime(time_zone="UTC")), pl.col("timezone_id"))
df.with_columns(datetime_local=pl.struct(["datetime_utc", "timezone_id"]).map_elements(convert_time_zone))  # current solution

@brendancooley how about this:
import polars as pl
from datetime import datetime
import pytz

df = pl.DataFrame({
    'id': [1,2],
    "date_col": [datetime(2020,10,10, tzinfo=pytz.UTC), datetime(2020,10,10, tzinfo=pytz.UTC)],
    'timezone': ['Europe/London', 'Africa/Kigali']
})

exprs =[
    pl.when(pl.col('timezone')==tz)
    .then(pl.col('date_col').dt.convert_time_zone(tz).dt.replace_time_zone(None))
    for tz in ['Europe/London', 'Africa/Kigali']
    ]

df.with_columns(
    pl.coalesce(exprs)
)

We can just add that we don't support python callables like the ones used in map_elements. I agree with @ion-elgreco that it's not really a problem. In general, avoid using map_elements in your code :)

Just to demonstrate, here is a gist of how we can serialize polars expressions using the write_json interface within pydantic models. In this case I'm reading the jsonified expression back in as a dict, since that is a nice type in python that you could do stuff with, but really we might just want to re-serialize the write_json string. It will end up double-escaped in the json file though, which I think is undesirable.
import json, polars as pl
expr = pl.col("foo") == 2

json.dumps(expr.meta.write_json())
# '"{\\"BinaryExpr\\":{\\"left\\":{\\"Column\\":\\"foo\\"},\\"op\\":\\"Eq\\",\\"right\\":{\\"Literal\\":{\\"Int32\\":2}}}}"'

Yes! I've just gone over it again, here it is: gist.github.com/thomasaarholt/c04ae8ad503a1476e5282e7098eeb1f7
I've called the result for each column a ColumnInfo class. I just needed a name that didn't have Field in it, cause I was going a little crazy 😅 .

I've just updated this with a bit more structure. This is my suggestion for how we avoid having to serialize anything to JSON.

@thomasaarholt a couple questions on the gist.
Take your simple model:
class SimpleExample(BaseModel):
    id: str                                                                    # pl.Utf8, required, not nullable, not unique, str, no constraints
    name: str                                                                  # pl.Utf8, required, not nullable, not unique, str, no constraints
    int_with_dtype_value: int = Field(json_schema_extra={"dtype": pl.Int16()}) # pl.Int16, required, not nullable, not unique, int, no constraints
    not_required_bc_has_default: bool = True                                   # pl.Boolean, not required, nullable, not unique, bool, no constraints

Is the intended API that users pass patito-specific field attributes via json_schema_extra?
How will pydantic-side field attributes be handled? e.g. ge, gt, multiple_of, min_length...
Is the intention for the expression/dtype serialization helpers to be implemented on the ColumnInfo class? Then when we override BaseModel.model_fields we know that pydantic will be able to successfully call model_json_schema?
What is the purpose of the type hint processors in the gist? Do we not already have some of this functionality implemented in Model._valid_dtypes

Great questions (really, it helps give me clarity too)

No. The intention will be to use a pydantic-like ´Field´ (link is to the branch that Jakob and I worked on) that will take the arguments you listed directly and pass them into pydantic's Field.
See 1. :)
My intention would be that the Patito Model overrides the model_json_schema method with something we construct that exports a working json string using the methods discussed with the gist above.
Model._valid_dtypes gets its info from Model._schema_properties which itself calls Model.model_json_schema. That means that it will try to serialize the polars types and expressions, which will fail. So my idea is that we create the valid_dtypes without going through the json route, which means parsing the type hints ourselves.

Note that in my SimpleExample, I am inheriting from BaseModel and not Patito's Model just because I needed an example that would run without installing Patito.

Great questions (really, it helps give me clarity too)

No. The intention will be to use a pydantic-like Field (link is to the branch that Jakob and I worked on) that will take the arguments you listed directly and pass them into pydantic's Field.
See 1. :)
My intention would be that the Patito Model overrides the model_json_schema method with something we construct that exports a working json string using the methods discussed with the gist above.
Model._valid_dtypes gets its info from Model._schema_properties which itself calls Model.model_json_schema. That means that it will try to serialize the polars types and expressions, which will fail. So my idea is that we create the valid_dtypes without going through the json route, which means parsing the type hints ourselves.

I like the idea of trying to override model_json_schema and handling the serialization on our end. But if we do that then we should be able to use Model._valid_dtypes as originally intended, right?

Huh. Yes, I guess 😅 That might be much more sensible! Would you like to try giving it an attempt? I will be a bit busy until Friday, but might be able to squeeze some of this in.

Huh. Yes, I guess 😅 That might be much more sensible! Would you like to try giving it an attempt? I will be a bit busy until Friday, but might be able to squeeze some of this in.

I'll give it a go!

Think we have a nice solution available here. There is a little work to do on the API and how to store and access the column info but wanted to share the serialization progress before proceeding. As you suggested, let's store patito-specific field attributes on a pydantic model:

from typing import Sequence, Any
import json

from pydantic import BaseModel, field_serializer
import polars as pl
from polars.datatypes import convert, DataTypeClass

class ColumnInfo(BaseModel, arbitrary_types_allowed=True):
    dtype: DataTypeClass | None = None  # TODO polars migrating onto using instances?  https://github.com/pola-rs/polars/issues/6163
    constraints: pl.Expr | Sequence[pl.Expr] | None = None
    derived_from: str | pl.Expr | None = None
    unique: bool | None = None

    @field_serializer('constraints', "derived_from")
    def serialize_exprs(self, exprs: str | pl.Expr | Sequence[pl.Expr] | None) -> Any:
        if exprs is None:
            return None
        elif isinstance(exprs, str):
            return exprs
        elif isinstance(exprs, pl.Expr):
            return self._serialize_expr(exprs)
        elif isinstance(exprs, Sequence):
            return [self._serialize_expr(c) for c in exprs]
        else:
            raise ValueError(f"Invalid type for exprs: {type(exprs)}")

    def _serialize_expr(self, expr: pl.Expr) -> Dict:
        if isinstance(expr, pl.Expr):
            return json.loads(expr.meta.write_json(None))  # can we access the dictionary directly?
        else:
            raise ValueError(f"Invalid type for expr: {type(expr)}")

    @field_serializer('dtype')
    def serialize_dtype(self, dtype: DataTypeClass | None) -> Any:
        """

        References
        ----------
            [1] https://stackoverflow.com/questions/76572310/how-to-serialize-deserialize-polars-datatypes
        """
        if dtype is None:
            return None
        elif isinstance(dtype, DataTypeClass):
            return parse_composite_dtype(dtype)
        else:
            raise ValueError(f"Invalid type for dtype: {type(dtype)}")

We use the field_serializer decorators to ensure that polars expressions and dtypes are serialized properly. Very clean implementation on the dtype serialization from @ radugrosu on stack overflow:
def parse_composite_dtype(dtype: DataTypeClass) -> str:
    if dtype.is_nested:  # TODO deprecated, move onto lookup
        return f"{convert.DataTypeMappings.DTYPE_TO_FFINAME[dtype.base_type()]}[{parse_composite_dtype(dtype.inner)}]"
    else:
        return convert.DataTypeMappings.DTYPE_TO_FFINAME[dtype]

we can go backward (from string to dtype) with the polars helper dtype_short_repr_to_dtype
def dtype_from_string(v: str):
    """for deserialization"""
    return convert.dtype_short_repr_to_dtype(v)

Now we can create an example pydantic model with ColumnInfo objects shoved into the json_schema_extra (we will later expose a nice API for users to pass patito-specific attributes directly to the Field constructor):
from pydantic import fields

class Model(BaseModel):
    a: int
    b: int = fields.Field(json_schema_extra={"column_info": ColumnInfo(constraints=[(pl.col("b") < 10)])})
    c: int = fields.Field(json_schema_extra={"column_info": ColumnInfo(derived_from=pl.col("a") + pl.col("b"))})
    d: int = fields.Field(json_schema_extra={"column_info":ColumnInfo(dtype=pl.UInt8)})
    e: int = fields.Field(json_schema_extra={"column_info":ColumnInfo(unique=True)})

With our custom field_serializers this serializes no problem 🎉 :
schema = Model.model_json_schema()
schema['properties']['c']['column_info']['derived_from']
>>> {'BinaryExpr': {'left': {...}, 'op': 'Plus', 'right': {...}}}
schema['properties']['d']['column_info']['dtype']
>>>'u8'

@thomasaarholt let me know if this is consistent with how you were thinking about this problem. I know you mentioned having issues with the field_serializers...does this solve some of the problems you were confronting? If you like this general approach I'll work on redesigning the patito Model internals to assume that the schema can be fully serialized, and try to provide a nicer frontend for patito Field construction.

I think this looks really great! Please go ahead!
Polars merged the dtype instance thing this weekend with release scheduled immenently in 0.18.0!

Edits with a first cut at the ColumnInfo implementation here
Serialization via model_json_schema now works nicely due to the pydantic field_serializers, but we expose a Model.column_infos property to allow the model to access the unserialized versions of patito-specific fields. Got all of the existing tests to pass and wanted to get this up to share progress. I'm going to write some more tests and some documentation tomorrow morning and will update with a more detailed usage guide then. As far as I can tell this does not alter the pt.Field API at all, users should have same experience as in pydantic v1.

https://github.com/JakobGM/patito/pull/32/commits/5f2b89e21d2301cfe3d7ec3a19b694c59ae88f21 creates a standalone dtype inference and validation module in the spirit of @thomasaarholt's wip gist. The main public functions are:

default_polars_dtype_for_annotation: takes a python annotation and returns single polars dtype, or None if no polars dtype is considered valid for the annotation.
valid_polars_dtypes_for_annotation: takes a python annotation and returns a set of polars dtypes that are valid. Returns an empty set if no dtypes are considered valid for the annotation.

We now call validate_polars_dtype on any column for which dtype is specified and validate_annotation on any column for which it is not when a `ModelMetaclass is instantiated. This allows us to proactively validate users' models and ensure that their annotations are consistent with their dtypes and vice versa. If the user tries to pass create the following model:
import patito as pt

class InvalidModel(pt.Model):
    text: str = pt.Field(dtype=pl.Float32)

a ValueError will be raised informing them that pl.Float32 is not valid for str annotated fields. Conversely if the user attempts to create a model with an unsupported type
class InvalidModel2(pt.Model):
    dict: Dict

a ValueError will be raised informing them that we could not find a polars dtype that supports the Dict annotation.
These make use of pydantic's TypeAdapter and I think make the dtype component of patito much more modular and extensible. I believe they are more robust to nested type annotations than the older code. And it should be much easier to add (for example) support for pl.Struct dtypes in the future (@ion-elgreco).
Note that pl.Float32 and pl.Float64 are now considered valid dtypes for integer annotations. I don't see any reason why this shouldn't be permitted, and it flowed very naturally from the way I set up the dtypes module, but I'm open to arguments that we should be more restrictive.

Now that we have the ColumnInfo objects I think we can cleanup the example generation and validation components of patito a bit as well, relying a little bit less on the parsing of the model_json_schema and exposing standalone components for easier testing. But this work could be tackled in the future.
A few more short term to dos:

[ ] are we committed to dropping duckdb support? I can delete associated code there if so
[ ] take a pass at the readme to make sure it is up to date with changes, are there other places where documentation should be added?
[ ] (optional) pydantic is now annotating json_schema_extra with JsonDict which is a fairly restrictive dictionary type. We may want to serialize our ColumnInfo prior to passing to pydantic.fields.Field in order to comply, but we'd need to work out the deserialization there first.
[ ] with the release of polars 0.20.0 we now have access to pl.Enum dtypes, which make a lot more sense than categorical to use with Literal annotations. Can migrate this logic over if we're in agreement on that (and willing to require polars>=0.20)

I think pinning the new version to Polars>0.20.0 is fine, also dropping DuckDB makes sense imho.
Btw @brendancooley i have a PR open in Polars for your specific usecase to create a local datetime ;)

Awesome!
Just a few thoughts based on your bullet points!

[ ] are we committed to dropping duckdb support? I can delete associated code there if so

Yes. We can always add it back later if we find it requested.

[ ] take a pass at the readme to make sure it is up to date with changes, are there other places where documentation should be added?

There is the docs directory which compiles into these docs. It would be great to go over that and ensure that it is up-to-date.

[ ] (optional) pydantic is now annotating json_schema_extra with JsonDict which is a fairly restrictive dictionary type. We may want to serialize our ColumnInfo prior to passing to pydantic.fields.Field in order to comply, but we'd need to work out the deserialization there first.

I need to take a deeper look here, but I think I get what you mean.
I asked on stackoverflow, and learnt a way to serialize based on the field type using model_serializer, rather than using field_serializer. I played around and wrote a gist that shows how to do this AND de-serialize with dataframes and expressions, and I think it should work with your solution for dtypes as well. That might reduce the field_serialize code in this PR by a little bit, and hopefully also let us deserialize the polars types too.

[ ] with the release of polars 0.20.0 we now have access to pl.Enum dtypes, which make a lot more sense than categorical to use with Literal annotations. Can migrate this logic over if we're in agreement on that (and willing to require polars>=0.20)

That seems very sensible to me!

[ ] I've jumped ahead a bit and used the python 3.10 syntax (int | None) in a bunch of places in the tests. If we want to keep python 3.9 support I can go back and turn these into Optionals and ensure that we pass the tests with python 3.9

As long as you aren't "instantiating" type aliases using the | operator (e.g. Foo = Bar | Baz) (note the equals sign), but only doing them as a type hints (e.g. foo: Bar | Baz), you can import from __future__ import annotations and you can use the new syntax in Python 3.9.

@brendancooley I've added the to_local_datetime functionality in polars-xdt: https://marcogorelli.github.io/polars-xdt-docs/api/polars_xdt.ExprXDTNamespace.to_local_datetime.html, that would solve your usecase :D
Also was wondering how progress was going of the migration? 👀 I honestly can't wait starting to use this hehe, it would allow me to make more flexible patito models

@brendancooley I've added the to_local_datetime functionality in polars-xdt: https://marcogorelli.github.io/polars-xdt-docs/api/polars_xdt.ExprXDTNamespace.to_local_datetime.html, that would solve your usecase :D There is also a from_local_datetime if you want to roundtrip
Also was wondering how progress was going of the migration? 👀 I honestly can't wait starting to use this hehe, it would allow me to make more flexible patito models than currently possible

Hoping to carve out time later this week to finish this up! Just need to polish and follow up on @thomasaarholt's notes from above and I think we'll have something ready to build upon.

@brendancooley alright, let me know if you need help with testing

docstrings and new readme to come. but lean, mean, db-free patito is pushed. I'll work on getting summaries of functionality onto the readme so that the changes explain themselves. But in the interim @ion-elgreco would love to have you take it for a spin and let me know how it looks.

@brendancooley 🚀🚀, I'm going to try it out now

@brendancooley Any idea on this error?
     1 """Module containing all custom exceptions raised by patito."""
      3 import pydantic
----> 6 class ValidationError(pydantic.ValidationError):
      7     """Exception raised when dataframe does not match schema."""
     10 class ErrorWrapper(pydantic.error_wrappers.ErrorWrapper):

TypeError: type 'pydantic_core._pydantic_core.ValidationError' is not an acceptable base type

@brendancooley datetime doesn't work if you doesn't contain TZ with .examples():
This will fix it:
if dtype.timezone is not None:
    tzinfo = ZoneInfo(dtype.timezone)
else:
    tzinfo = None
return datetime(
    year=1970, month=1, day=1, tzinfo=tzinfo
)

Adding dtype in pt.Field(dtype=) breaks validation for datetimes:
class Test(pt.Model):
    date_value: datetime = pt.Field(dtype=pl.Datetime)

Test.validate(pl.DataFrame({"date_value": [datetime(2020,1,1)]}))

DataFrameValidationError: 1 validation error for Test
date_value
  Polars dtype Datetime(time_unit='us', time_zone=None) does not match model field type. (type=type_error.columndtype)

GE constraint not respected while creating examples:
class Test(pt.Model):
    value: int = pt.Field(ge=0)

print(Test.examples())
shape: (1, 1)
┌───────┐
│ value │
│ ---   │
│ i64   │
╞═══════╡
│ -1    │
└───────┘

This should return 0 or larger :)

So, besides these small bugs everything works as expected!

awesome @ion-elgreco, should be good to go on all of these now

@brendancooley awesome! Then I think it's in a state to release now☺

Left a couple small comments, really nice work @brendancooley!
Hope we can get this merged soon @thomasaarholt :)

Useful for knowing where to flesh out the docs -- thanks!

Awesome! @thomasaarholt can't wait for the release

Doing it right now

Released now on github, should be on pypi shortly!

I see that the pypi release action failed, because everythibg has to pass. 😬 I'll see if I can tone down the requirements this evening.

We are live now with 0.6.1! https://pypi.org/project/patito/

Woohoo 🎉🎉

Awesome, thanks @thomasaarholt. Excited to do more with this, glad that we have a stable foundation to build on top of.

authors: brendancooley ion-elgreco thomasaarholt

repo: JakobGM/patito


text:
JsonConvert.PopulateObject() doesn't play nicely with JsonExtensionDataAttribute

Source/destination types
public class Something
{
	public int Foo { get; set; }

	[JsonExtensionData]
	public IDictionary<string, JToken> Extra { get; set; }
}

Source/destination JSON
JSON object 1
{"Foo": 1, "Bar": 2}

JSON object 2
{"Foo": 3, "Bar": 4}

Expected behavior
JsonConvert.PopulateObject() should not throw any exceptions when called with a valid JSON and an instance of the Something class.
Actual behavior

The following exception is thrown:
Message
Error setting value in extension data for type 'UserQuery+Something'. Path 'Bar', line 1, position 19.

Source
Newtonsoft.Json

StackTrace
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.SetExtensionData(JsonObjectContract contract, JsonProperty member, JsonReader reader, String memberName, Object o)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.PopulateObject(Object newObject, JsonReader reader, JsonObjectContract contract, JsonProperty member, String id)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Populate(JsonReader reader, Object target)
   at Newtonsoft.Json.JsonSerializer.PopulateInternal(JsonReader reader, Object target)
   at Newtonsoft.Json.JsonConvert.PopulateObject(String value, Object target, JsonSerializerSettings settings)
   at Newtonsoft.Json.JsonConvert.PopulateObject(String value, Object target)
   at UserQuery.Main()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

TargetSite

RuntimeMethodInfo:
JsonSerializerInternalReader.SetExtensionData (JsonObjectContract contract, JsonProperty member, JsonReader reader, String memberName, Object o)

Steps to reproduce
Please run the following code. Exception is thrown on the second invocation of JsonConvert.PopulateObject().
	var something = new Something();

	JsonConvert.PopulateObject(@"{""Foo"": 1, ""Bar"": 2}", something);
	JsonConvert.PopulateObject(@"{""Foo"": 2, ""Bar"": 3}", something);

Versions
Tested on 11.0.2

Fixed. Thanks for the detailed repo.

Awesome, thank you!

authors: JamesNK yuretz

license: mit


text:
No Deserialization of Booleans with Dynamic

If I have JSON
{
     "isWriteable":true,
     "isReadable":false
}

And then I try to deserialize this with (where the variable 'json' contains the JSON above), as in:
var jsonObj = JObject.Parse(json);

If I try to do
if (jsonObj.isWriteable) {
   // blablabla
}

The code above compiles fine, but upon running I get an Exception:
Microsoft.CSharp.RuntimeBinder.RuntimeBinderException : Cannot implicitly convert type 'Newtonsoft.Json.Linq.JValue' to 'bool'. An explicit conversion exists (are you missing a cast?)

Really, there should be native dynamic bool support.  Right now, as it stands, I have to do
if (jsonObj.isWriteable.Value) {
    //blablabla
}

which is just plain cumbersome.  Being able to do it by just reading the property directly in the if would be so much more elegant.

Just ran into this too.

How is this still not fixed?

authors: Flaflo astrohart ruaanviljoen


text:
Some operational issues.

Hello. Your work is a great research. I encountered some issues while running your code. How can I obtain the files referenced by 'B' and 'A' in example. py.

Thank you for your interest in our project !
You must be mentioning the path for the test data: one path for the burst and one for the exposure ratios. I have just pushed a release that contains 50 burst for both single-exposure and multi-exposure. For multi-exposure, 3 noise levels on the ratios can be used. For single-exposure, you must generate them as exposures = np.ones(N), N being the number of frame in the burst (15 in the example).

repo: Jamy-L/handheld-sr-satellite


text:
Add record builder helpers

This PR adds 3 functions:

Random.chain: the core for composing two Generators with record builders
Random.map: maps over a field in a record builder
Random.static: provides a constant value for a record builder field

Sorry, meant to make a PR into @lukewilliamboswell 's fork and trusted GitHub's suggested PR too much. Closing.

repo: JanCVanB/roc-random


text:
Concurrent whenNext/putNext/putFinal

test("whenNext: concurrent put final") {
var exptectedValue: Option[Immutability] = None
for (_ <- 1 to 1) {
  implicit val pool = new HandlerPool
  val completer1 = CellCompleter[ImmutabilityKey.type, Immutability](ImmutabilityKey)
  val completer2 = CellCompleter[ImmutabilityKey.type, Immutability](ImmutabilityKey)

  val cell1 = completer1.cell

//      THIS IS A SEQUENTIAL VERSION WHILE DEV OF THIS TEST. SEE BELOW FOR CONCURRENT VERSION
  cell1.whenComplete(completer2.cell, _ => NoOutcome) // (3)
  cell1.whenNext(completer2.cell, _ => NextOutcome(Mutable)) // (2)
  completer2.putFinal(Mutable) // (1)

  //      CONCURRENT VERSION

//      pool.execute(() => cell1.whenComplete(completer2.cell, x => {
//        NoOutcome
//      }))
//
//      pool.execute(() => cell1.whenNext(completer2.cell, x => {
//        if (x == Mutable) NextOutcome(Mutable)
//        else NoOutcome
//      }))
//      pool.execute(() => completer2.putFinal(Mutable))
  val fut = pool.quiescentResolveCycles
  Await.ready(fut, 2.seconds)

  println(cell1.getResult())

  if (exptectedValue.isEmpty) exptectedValue = Some(cell1.getResult())
  else assert(cell1.getResult() == exptectedValue.get)

  pool.shutdown()
}

}

This test has been added to phaller's repo.

repo: JanKoelzer/reactive-async


text:
minor bug: DOI in insertion table but not DB

Check out 10.12688/f1000research.146327.2, the second DOI from the bottom:

A search for this DOI in the browser interface says it's not stored locally, yet it has jrc_inserted metadata in that lookup table.

Will modify code to strip leading/training spaces

authors: robsv virginiascarlett

repo: JaneliaSciComp/dis-utilities


text:
Elide default parameter settings, add benchmarks

I added some benchmarking tests and then reduce the number of native synchronized calls.
For 100 chunks of 16 MB of (short) (rand.nextGaussian() * Short.MAX_VALUE/2048.0 + 255), I get the following results.
The test parameter pairs are {compression_level, number_of_threads}. Timings are for the entire AbstractN5Test suite. The traditional tests take about a second to run in total. The rest of the time is spent compressing the 100 chunks .
    	int m = Zstd.minCompressionLevel();
    	int M = Zstd.maxCompressionLevel();
    	System.out.println("Minimum compression level: " + m);
    	System.out.println("Maximum compression level: " + M);
    	//Comments below are with 16 MiB of int16 255 +/- 32;
		return Arrays.asList(new Object[][] {
			{ m,0}, { m,2}, { m,4}, { m,8}, // test  0 -  3, 100%,  3.5s, 1 thread
			{-2,0}, {-2,2}, {-2,4}, {-2,8}, // test  4 -  7,  97%,  4.5s, 1 thread
			{-1,0}, {-1,2}, {-1,4}, {-1,8}, // test  8 - 11,  96%,  5.0s, 8 threads
			//Compression level 0 means default (3)
			{ 1,0}, { 1,2}, { 1,4}, { 1,8}, // test 12 - 15,  55%,  5.5s, 8 threads
			{ 2,0}, { 2,2}, { 2,4}, { 2,8}, // test 16 - 19,  53%,  8.1s, 4 threads
			{ 3,0}, { 3,2}, { 3,4}, { 3,8}, // test 20 - 23,  51%, 14.0s, 4 threads
			{ 6,0}, { 6,2}, { 6,4}, { 6,8}, // test 24 - 27,  49%, 25.5s, 2 threads
			//{12,0}, {12,1}, {12,2}, {12,4}, // test 28 - 31
			//{15,0}, {15,1}, {15,2}, {15,4}, // test 32 - 35
			//{ M,8}, { M,1}, { M,2}, { M,4}  // test 36 - 39
		});

The effect of eliding unncessary native synchronized calls saved at most 100 ms.

After enabling the elision, I got the following timings. The effect is not great.
3.3s
4.5s
5.1s
5.5s
8.2s
13.9s
25.4s

@axtimwalde I'm going to push this through into FIJI so that it available as soon as possible.


text:
Feat/76 update column validation

#76

@Jank1310 wofür willst du den enum diff? Ist mir nicht ganz klar. Delete ist ja auch garnich supported.

@Jank1310 wofür willst du den enum diff? Ist mir nicht ganz klar. Delete ist ja auch garnich supported.

Wenn man zum Beispiel eine neue Abteilung in DD erstellt, wäre es einfacher, wenn ich beim Callback mitbekomme: "Es wurden zwei neue Abteilungen erstellt", dann kann ich die anlegen, bevor ich die Daten bei mir importiere

@Flofie Any updates on this?


text:
Feature merge from enhex fork

Basically changes from https://github.com/Enhex/premake-cmake/pull/16 plus one additional change (honoring C(XX)FLAGS) as well as two regression fixes.

@tritao: Conflicts are indeed blocking,
Then I have to test it. (fortunately I have https://github.com/Jarod42/premake-sample-projects for that).
Sorry for delay :-/ (wrong notification settings :/ )


text:
Allow arguments to get_survey_questions()

I'm using parameter includeLabelColumns for get_survey_responses(), and it would be helpful to allow this parameter in get_survey_questions() too, so that the universe of questions matches between the two endpoint returns.

@rlittle08 fixed added in latest version.

repo: Jaseibert/QualtricsAPI


text:
SAML: add securitymanager property

Adds a property to control the security manager class for opensaml in the cas-server-support-saml package. This is used to support jdk8 by setting it to com.sun.org.apache.xerces.internal.util.XMLSecurityManager or to use Xerces with org.apache.xerces.util.SecurityManager

:+1: with a comment on organization of comments.
Also, please update the documentation.

Done

Perfect! Thank you.

One last thing, I do still see doc updates missing from this PR. You'll find the docs under the documentation module in master. Please update those as well to make this new setting known.

I'd just forgotten to actually commit it before pushing...

Thanks again. I marked this for 4.2, given that we are now in RC mode and this isnt really a bug as we don't support JDK8 yet officially. Once 4.1 is out, this could go into master, and 4.1.x.

replaces https://github.com/Jasig/cas/pull/1120

I'm not entirely sure XMLSecurityManager is needed for jdk8. I do know I get a cast exception without changing it to org.apache.xerces.util.SecurityManager. I get a ClassNotFound exception for XMLSecurityManager.

What is the Java version you run?

openjdk8 on ubuntu 15.04

OK, so that's where you ClassNotFound issue comes in. We don't officially support Java 8, and we also don't support OpenJDK. In your dependency list, you probably have xerces pulled in somehow which causes the cast issue.

Xerces is being pulled in by the cas-server-support-openid.
The relevant section of mvn dependency:tree
[INFO] +- org.jasig.cas:cas-server-support-openid:jar:4.1.0-RC3-SNAPSHOT:compile
[INFO] |  +- org.openid4java:openid4java:jar:0.9.8:compile
[INFO] |  |  +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] |  |  +- net.sourceforge.nekohtml:nekohtml:jar:1.9.10:compile
[INFO] |  |  +- com.google.inject:guice:jar:2.0:compile
[INFO] |  |  \- xerces:xercesImpl:jar:2.8.1:compile
[INFO] |  \- org.apache.httpcomponents:httpclient:jar:4.4.1:compile
[INFO] |     \- org.apache.httpcomponents:httpcore:jar:4.4.1:compile

If is possible to exclude xerces from that openid module? Would that cause issues? If not, we could directly exclude it in source.

It may be. I'll try when I get a chance today.

Great. If you are successful, please issue a separate PR. Thanks again.

It works with xerces excluded. I will send a PR to exclude that dependency instead.

Much appreciated. That PR, we can include in 4.1.

authors: mmoayyed tduehr

repo: Jasig/cas


text:
Update readme.md file

update the website screenshot with the new UI screenshot

If the issue is still open, I'd like to contribute


text:
Merge pull request #2 from JasonGrahamAZ/main

checking  headers

Making headers

Making header

finish


text:
[Bug]Cannot paste what I have copied after Notepads is closed

I copy some texts in Notepads.
When Notepads is running I can paste what I have copied to other places.
But after Notepads is closed it seems that what I copied is lost and cannot paste.
I'm not sure whether it's a bug, a feature or the limit of UWP Applications.

It is by default and I have tried this: https://github.com/JasonStein/Notepads/commit/62a02338d3619da5acd77ffdc4eb8e408e640f3a
It does not help.

Actually adding Clipboard.Flush(); after SetContent works. So I guess I fixed your problem here:
https://github.com/JasonStein/Notepads/commit/98f34c3c2939df27c703c4deb0fa22fb94fdd76a

Close this issue since v0.9.6.0 is alive.

authors: JasonStein Threonine-Animist

repo: JasonStein/Notepads


text:
连接速度比较慢的解决办法

将BleManager.java中的
    private void connect(BluetoothDevice device, BleGattCallback callback) {
        bleBluetooth.connect(device, true, callback);
    }

这里的第二个参数是智能连接,如果开启了智能连接,会影响连接速度,我测试过,开启智能连接速度会是不开启的十倍,项目中可以修改默认为false,或者直接丢到外部给人使用,体验效果会好点

还有,我讲这份代码加到我的常用库中,应该是可以的吧,没有具体看你这个库的开源协议

谢谢你的建议。另外开源没有问题。

authors: Jasonchenlijian lvzhongyi

repo: Jasonchenlijian/FastBle


text:
Marten.CommandLine "patch" on up-to-date database drops and recreates indexes

When running against a fully updated database (ie, after running the Marten.CommandLine apply command), the patch command appears to drop and recreate all indexes that have previously been deployed.  Since indexing can be an expensive proposition, shouldn't these be skipped instead?
(Note that this script was created with AutoCreateSchemaObjects = AutoCreate.CreateOrUpdate and DdlRules.TableCreation = CreationStyle.CreateIfNotExists.)

I think the bigger question might be why Marten thinks your indexes have changed

No idea, unless postgres 10 is doing something interesting when I'm not looking.

@droach282 are you using any multi-key indexes? I fixed #1018, a little while ago, this could possibly related to this issue.
In any case please post an example of the index which you created to check on this.

@droach282 thanks for the repro, I was able to zero in on the issue and the fix is on its way

Good deal, thanks Babu!

On Jul 17, 2018, at 10:56 AM, Babu Annamalai notifications@github.com wrote:
@droach282 https://github.com/droach282 thanks for the repro, I was able to zero in on the issue and the fix is on its way
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/JasperFx/marten/issues/1043#issuecomment-405652899, or mute the thread https://github.com/notifications/unsubscribe-auth/ABtNpXQfgPc0uI8NpUXa2A3PQp4h9P2lks5uHhdNgaJpZM4VNogT.

Fixed by https://github.com/JasperFx/marten/pull/1047. Will be in Marten 2.9.0

authors: droach282 jeremydmiller mysticmind

repo: JasperFx/marten