Making RealWorld “realer” (2.0?)

This past year I’ve been trying out lots of different front end libraries, and was very happy to discover this project and the community around it.
I’ve been thinking about posting this comment for a while, as I’ve noticed these libraries have a fundamental design difference that RealWorld in its current form doesn’t account for: modularity and reuse.
It seems front end libraries fall into two categories - they either support some kind of architecture for modular reuse (often a stateful component concept) or they don’t.
The Conduit front end, per the current spec, does not present any use-case for any kind of UI control with any internal/accidental state - and while that may be realistic for some simple apps, in my experience, it isn’t enough for larger, more complex apps.
Almost every real-world (duh) app features some kind of recurring UI control that has some kind of state that’s only relevant while the control is on-screen.
Let me give a couple of examples to clarify what I’m talking about.
My favorite example is a drop-down date-picker. It has the selected date state, which is relevant to the application, and therefore typically bound to the application state rather than stored internally in the control instance. But it also has state indicating whether the control is currently open, which month is currently showing, and so on - I refer to this state as accidental, because it is typically of no relevance to the application, and it’s only relevant while the control is visible.
Another example is an auto-complete input. It has the selected value, which is relevant to the application. But also may have an XHR instance, a list of values, the current cursor position in the list, and so on - all of which are accidental, irrelevant to the application, and relevant only while it’s displayed.
It’s not that these kinds of controls can’t be implemented with stateless components/views, they can of course - but the application will need to maintain all this irrelevant state somewhere, and will need to manually keep track of visible controls etc. so that, for example, switching to a different tab in the UI correctly clears the state of, say, a date-picker that is currently open, since the user would likely find it confusing to return to a previous tab and find a date-picker (that they didn’t just click on) already open.
Implementing all this state management and wiring can sometimes be difficult in front-end libraries that don’t provide any kind of concept for modular reuse - sometimes near impossible.
Almost every major React, Vue or Angular project uses either third-party or first-party components/controls that have accidental state, so it seems pretty relevant, I think.
Something to think about for v2.0 maybe?

Hi @mindplay-dk 😄
So is your thought that we should break down the front end spec into individual components with some guidance on component state management?
I think that works for most frameworks and could be super useful as a learning tool when digging into a particular framework. It could certainly make realworld more realworld (see what I did there 😂)
The downside in my opinion is the the learning curve that adds for someone who is just getting into looking at a framework. Typically, at least in my experience, when you start learning a framework you are learning the api's, conventions, and structure; then as you get comfortable with those things you begin to really leverage component reuse and more efficient state management.
I'd be a little hesitant to make those things bare minimum but I'm for sure open to keeping the discussion open and seeing how we make components and state management more of a focus on the next spec version.
@anishkny?

So is your thought that we should break down the front end spec into individual components with some guidance on component state management?

Not at all :-)
I don't think we can/should provide any general guidance on component state management, or anything else that resembles architecture - because this is where the frameworks differ. The spec shouldn't dictate anything other than the expected end result - each implementation should leverage whatever concepts are available in the selected frameworks/libraries. That's sort of the whole point, I think? :-)
What I'm pointing out is the fact that, for example, if you were going to implement the Conduit front-end with, say, React, you could do so entirely using functional components - there's no recurring control in the UI that substantially benefits from using the stateful component abstraction.
In other words, we're not leveraging or exercising the concepts that make React interesting.
There are several ultra-lightweight UI frameworks/libraries of 1-2 KB that only support the equivalent of stateless functional component - any of these can be used to implement Conduit's front-end without problems.
But that's unrealistic - as said:

Almost every real-world (duh) app features some kind of recurring UI control that has some kind of state that’s only relevant while the control is on-screen.

Conduit's UI doesn't have any controls in that category.
It has recurring portions of UI, but none of those portions are "controls" in the sense that they have individual state tied to their individual life-cycle.
I'm suggesting we need to think of an additional feature/case that calls for e.g. stateful components in React, or other features in other libraries using whatever concepts those offer for reusable controls. (some of them don't offer anything, and that will lead to interesting results not currently seen in implementations - which will either demonstrate limitations/weaknesses or alternative patterns that illustrate why those concepts aren't necessary when using those libraries.)

For me how state/route is implemented should be for each example. I do wish that there was a forgot password built into all the examples, and a few examples of uploading files for each framework which would save many people time.

@lastlink I think those issues are interesting, but unrelated and belong in a separate discussion.

There is still, to my knowledge, no demo project suite out there that requires control state.
It's a bit frustrating - so many new frameworks don't support this (to any practical extend) and a lot of developers aren't going to realize that before it's too late, as many rely on this demo suite to evaluate whether a given framework "works".
I believe most projects will eventually need control state - a lot of these frameworks wouldn't support it, and if you built a large project by the time you realize that, you'll have to either make an expensive switch to a different framework, or (worse) hand-write code to manage arrays of control state as part of your application state, manually manage a control state life cycle, and so on.
I wish you would raise the bar on these frameworks, so we can see how they really hold up in the real world. I think that's the purpose of this project?

@mindplay-dk Could you maybe try to create an upgrade to the current spec and maybe create an example for one of the implementations with something that you think would add what you are talking about?

@Alonski we would need to think of a new feature that actually requires a component that has some sort of control state and occurs more than once.
Maybe an advanced search form with start and end date pickers? The main problem with that idea is that calendar logic is quite complex and doesn't really help demonstrate anything relevant in terms of comparing UI libraries. You've picked a source of reference (Medium) that by design is very minimalist in terms of UI and avoids basically anything that requires a stateful control.
Plenty of admin forms, for example, would require various stateful controls - maybe we could think of a back-end/admin screen of some sort that has a more complex form?
I'll keep thinking about it, but it's actually difficult to think of something for this kind of app.

Also most date pickers are wrappers around existing ones. Needs to be something that you can't just npm install a fix for.

I do have a small date picker that I keep porting to different frameworks for testing - it's only around 50 LOC for the calendar logic...
https://gist.github.com/mindplay-dk/d85fbf5427d5e4436fadc70ce46d9ac2
I would prefer finding a feature that doesn't require everyone to copy/paste 50 lines of logic though. It might have bugs, never really used or tested ;-)

I was most surprised when a forgot password wasn't included in the frontends.

I was most surprised when a forgot password wasn't included in the frontends.

@QuantumInformation that doesn't really present a new change to the frameworks though - just more of the same. The point of this thread is, there's an entire class of components with instance-specific state that isn't covered by any of the current cases - and this appears to be something that significantly sets frameworks apart.

Yeah, but it would be just nice to have one less thing to implement when bootstrapping an app from this code.
Great work though!

@mindplay-dk

There is still, to my knowledge, no demo project suite out there that requires control state.
If you think about the TodoMVC as a control part of a larger application, rather than an application in its own right, then you have one.

so many new frameworks don't support this (to any practical extend) and a lot of developers aren't going to realize that before it's too late, as many rely on this demo suite to evaluate whether a given framework "works".

Folks have been writing web applications with jQuery and direct DOM manipulation and plenty of controls without a hitch. I don't think the situation would dramatically change with any framework, small or large. It is not like you need a framework to manage state of any kind, worse case you do it yourself (plain vanilla-JS, web components etc.) or with an extra library -- there are just plenty of options. For instance, there are standalone implementation of Hooks (a-la React Hooks) that can be used in any framework. My point is you never reach a point where it is too late. You just go about things differently.
I do agree that scope is something that sets frameworks apart. Focusing only on the UI is certainly a different value proposition as doing scheduling, suspense, state management, effects and what not in the same framework.
It is also true that the more complex the application, the more resorting to a complex framework is an interesting choice -- that is actually why we have frameworks: to achieve productivity through reuse, and higher readability and maintainability through consistent patterns. Looking at the picture only through the lens of performance (as does this benchmark), leads to focused UI libraries and plain JS to be sure winners.
On the subject of RealWorld 2, I totally support that, but I would not necessarily focus on what may seem on first look as artificial technical details. I would just try to find, well, a real-world app, that people can understand just by the title description. What comes to mind are booking systems (restaurants, plane tickets) or generally e-commerce systems. Those applications generally feature a stateful multi-step process with plenty of forms, and which can be difficult to implement properly and concisely.
As a final world, let's not forget the goal, which is to compare the implementation of the same application with multiple frameworks on a credible application. If you are by design choosing features of this application that are best handled in large frameworks, you are biasing the effort. If you are choosing features of this application to make it simple, you are also biasing the effort towards specialized UI libraries. I would say find a real application, in the sense of a real, consumer site not in the sense of complex or else. Then if that app needs a date picker, then that's that.

there are standalone implementation of Hooks (a-la React Hooks) that can be used in any framework

This gives you state - but it doesn't somehow give you update boundaries pertaining to that state.
Some of the simpler libraries will let you render and update JSX - if you use this approach with one of those libraries, any state update will necessarily cause a complete render/diff of the entire UI.

If you are by design choosing features of this application that are best handled in large frameworks, you are biasing the effort.

I don't think I'm doing that?
Even a tiny app like, say, a cookie consent banner, might have a few tabs and a custom drop-down - if you're going to package and deploy that, you most likely want a very small framework you can embed.
Of course you can render and diff the entire application top-down on every input keystroke - and of course you can manually create and manage the life-cycles and every detail of every control by modeling everything as application state. But performance will be pretty awful, and the resulting code will be a jumbled mess of application/control state and instance management.
I've personally found that this requirement can surface for even the simplest of use-cases - so I don't think this isn't about "large or small" at all, it's about handling a fundamental UI requirement in a sensible manner.
For example, this tiny 512 byte library does support control state. That's small, right? So this isn't just handled by "large frameworks".
And if you still think this requirement is biased towards a particular approach, or a particular type of abstraction, I disagree - this is simply another UI case demonstrating a real-world problem.
It doesn't dictate a specific solution, or even a framework solution. If the person implementing the app can demonstrate a simpler, better, faster or cleaner approach to solving the problem with a particular library, whether the library implements it as a feature or prescribes a particular pattern, I'd like to see how they compare.
My suspicion is that, yes, some libraries will be able to handle control state more/less elegantly than others - but that's pretty much the case for every challenge presented by RealWorld, I think: the whole point of it is to compare implementations using the libraries and the patterns they prescribe, to see how they fare in different situations.
In that sense, the whole project is opinionated or biased towards solving certain problems.
I don't see how that's a bad thing, and I don't believe this requirement is exotic or rare at all.

there are standalone implementation of Hooks (a-la React Hooks) that can be used in any framework
This gives you state - but it doesn't somehow give you update boundaries pertaining to that state.

I am not sure what you mean by that. TNG-hooks for instance lets a component access and update state, and that state would be only accessible from that component (is that what you mean by boundary?). The same state management abilities can be even more easily achieved with a simple closure (whose scope you can adjust).

For example, this tiny 512 byte library does support control state. That's small, right? So this isn't just handled by "large frameworks".

That is a good find. I had not hear about it. I am actually writing the Realworld app as Kingly state machine, and I decided to use Svelte. What is interesting with Kingly is that you can switch your UI without changing the machine (the machine encodes the specs, so if the specs do not change, the machine does not). I already have demonstrated a movie search app in 7 different UI libraries with the exact same machine. So I could use dot.dom for my second implementation of the Realworld app. I will see how it goes, but if the process is smooth, I might just have the Realworld app in 14 different UI libraries.

In that sense, the whole project is opinionated or biased towards solving certain problems.

I agree it is kind of impossible to eliminate bias completely. My point is that I am more interested in the real part of real app that in the technical challenges of the app, so the primary driver for picking up the next app would be for it to be realistic. In other words, I am interested in the challenges of a realistic app rather than in creating a ficticious app with specific challenges.

This gives you state - but it doesn't somehow give you update boundaries pertaining to that state.

I am not sure what you mean by that. TNG-hooks for instance lets a component access and update state, and that state would be only accessible from that component

Yes, TNG-hooks lets a component access and update state while it is rendering - by render boundaries, I mean, control of where rendering begins and ends: the scope of an update.
You can tie-in TNG with, for example, this tiny library - and this will give you stateful components during updates, but it won't somehow imbue it with any concept of render boundaries for those components... So, anytime a single state value changes anywhere in the application, you will have to update the entire UI top-down.
If a library doesn't have the ability to update individual components, TNG can't fix that - and practically any library that has the ability to update individual components also has some kind of component instance, implying some sort of component life-cycle, and most likely some means of associating state with those instances.

if the process is smooth, I might just have the Realworld app in 14 different UI libraries.

Wow! I wish I had that kind of energy :-)

I am interested in the challenges of a realistic app, whatever they turn out to be, rather than in creating a ficticious app with specific pre-determined challenges.

I don't think there's anything ficticious about control state - I personally see this need coming up even in very small apps much simpler than RealWorld. Even some of the primitive, standard, native browser elements, such as <select>, have control state.
Anyhow, we can agree to disagree on this point :-)

Alright I think I understand what you mean. Without a component
concept, you cannot have a component granularity basically. But you
can always build your own component concept around the minimal UI
library if you need to. Or you can memoize some of the vDOM generating
functions so they don't recompute. Or you can just accept the virtual
DOM cost.  I agree that it may be an hassle and this may come with
tricky edge cases that a componentized UI library has already solved
for its users.For me what you mention is more of an optimization
problem (minimizing unnecessary vDOM computations) that is common to
all vDOM-based UI libraries, than a breaking point.
Thinking about it, I believe though that template-based UI libraries
would probably not have that problem, as the UI library can deduce
from the template the exact DOM operation to perform when a dependent
state variable changes. So you could have a single template without
any component, and you would only see surgical updates of the DOM.
That is how Svelte works, but also probably Vue.
About Realword app and the 14 implementation of it, this is because I
already did the same app with 7 UI libs, so it is double that because
a man needs to challenge himself. It is not that time consuming, given
that with the Kingly state machine library, the UI library only ever
does rendering and that is pretty much the same in every library so
the process is smooth. There are always some tiny differences in
syntax but that is generally quickly solved. But it surely is a
repetitive process.
On 8/10/19, Rasmus Schultz<EMAIL_ADDRESS>wrote:

This gives you state - but it doesn't somehow give you update boundaries
pertaining to that state.

I am not sure what you mean by that. TNG-hooks for instance lets a
component access and update state, and that state would be only accessible
from that component

Yes, TNG-hooks lets a component access and update state while it is
rendering - by render boundaries, I mean, control of where rendering begins
and ends: the scope of an update.
You can tie-in TNG with, for example, this tiny
library - and this will give you
stateful components during updates, but it won't somehow imbue it with any
concept of render boundaries for those components... So, anytime a single
state value changes anywhere in the application, you will have to update the
entire UI top-down.
If a library doesn't have the ability to update individual components, TNG
can't fix that - and practically any library that has the ability to update
individual components also has some kind of component instance, implying
some sort of component life-cycle, and most likely some means of associating
state with those instances.

if the process is smooth, I might just have the Realworld app in 14
different UI libraries.

Wow! I wish I had that kind of energy :-)

I am interested in the challenges of a realistic app, whatever they turn
out to be, rather than in creating a ficticious app with specific
pre-determined challenges.

I don't think there's anything ficticious about control state - I personally
see this need coming up even in very small apps much simpler than
RealWorld. Even some of the primitive, standard, native browser elements,
such as <select>, have control state.
Anyhow, we can agree to disagree on this point :-)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/gothinkster/realworld/issues/262#issuecomment-520136166

--

you can always build your own component concept around the minimal UI library if you need to

Of course, you can always build your own library on top of another library.
But the point of RealWorld, I think, is to show what you can do with a given library and appropriate patterns?
If I had to build my own component abstraction with diffing and life-cycle management and all, on top of another library, that new library becomes a candidate for a separate case-study and implementation.

For me what you mention is more of an optimization problem (minimizing unnecessary vDOM computations) that is common to all vDOM-based UI libraries, than a breaking point.

Up to a point, sure - it depends on the overall complexity of the UI.
If it's large enough, rendering everything top-down, at every keystroke in every input, becomes untenable - you can't reasonably ship an app that lags and bogs down the UI thread at every keystroke.
Real world projects often have a screen with, for example, an information-dense table and an edit-form being visible at the same time. Nobody wants to start building an entire project with a chosen library, just to discover down the line that it's complete infeasible in practice for a use-case that emerges later.
The assurance I personally hope to get from something like RealWorld, is that a given library and it's associated patterns work, and keep working, in the real world - otherwise, I don't know what the point is. If you're not concerned about scaling to the complexities of real UI, TodoMVC would likely suffice.

Alright, so I guess that if my point is not clear, then indeed example
of implementations around miscellaneous UI lib will do a better job to
dispel any doubts.
On 8/19/19, Rasmus Schultz<EMAIL_ADDRESS>wrote:

you can always build your own component concept around the minimal UI
library if you need to

Of course, you can always build your own library on top of another library.
But the point of RealWorld, I think, is to show what you can do with a given
library and appropriate patterns?
If I had to build my own component abstraction with diffing and life-cycle
management and all, on top of another library, that new library becomes a
candidate for a separate case-study and implementation.

For me what you mention is more of an optimization problem (minimizing
unnecessary vDOM computations) that is common to all vDOM-based UI
libraries, than a breaking point.

Up to a point, sure - it depends on the overall complexity of the UI.
If it's large enough, rendering everything top-down, at every keystroke in
every input, becomes untenable - you can't reasonably ship an app that lags
and bogs down the UI thread at every keystroke.
Real world projects often have a screen with, for example, an
information-dense table and an edit-form being visible at the same time.
Nobody wants to start building an entire project with a chosen library, just
to discover down the line that it's complete infeasible in practice for a
use-case that emerges later.
The assurance I personally hope to get from something like RealWorld, is
that a given library and it's associated patterns work, and keep working,
in the real world - otherwise, I don't know what the point is. If you're not
concerned about scaling to the complexities of real UI, TodoMVC would likely
suffice.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/gothinkster/realworld/issues/262#issuecomment-522449111

--

I would also like to see and work on v2. The one big thing that I think is missing in v1 is indeed more complex forms with validations. I was looking at the react and the apprun implementations and they don't seem to do client side validations on the login and registration forms. crizmaz-mvc does. Also in the crizmas-mvc example I'm presenting some pending state as well, for instance the 'favorite' heart button is disabled while the request is pending. The react and apprun examples don't implement something like that. I think it would be good for the spec to have such ux details as well.
Regarding forms, a nice to have scenario would be one that includes a wizard with a few pages (such that parts of the wizard are not rendered) and with lists of rows of fields. Perhaps adding and removing rows dynamically. It would be nice to have expandable/collapsible sections in order to challenge libraries that keep state in the components so that the validation state could be lost when the section is collapsed. It would be interesting to allow jumping from one step of the wizard to another that has already been completed and maybe allow to enter some invalid date and then allow jumping to the last page where the user submits. In that case the submit shouldn't work and maybe redirect to the user to the step where the field had an invalid value. Even more interesting would be to have to reuse that in multiple areas of the application.
Also another interesting aspect is presenting the same data/state in different parts of the application without losing that data/state when the context changes, so that we can see how the separation of concerns is addressed. All in all, we should have more complexity.
I think the focus shouldn't be on more sophisticated components such as datepickers or typeaheads because frameworks typically don't provide them. If 3rd party components are used, the size of the bundle might look different depending on the library. Or, if needed then at least have some not too complicated implementation that can be ported to each framework (meaning, not too much tied to a specific framework).

It would be nice to have expandable/collapsible sections in order to challenge libraries that keep state in the components so that the validation state could be lost when the section is collapsed.

This is somewhat related to the problem I've been trying to define.
The very easy work-around is to just use CSS to control visibility, however - the problem I've been trying to describe is a bit trickier in that regard, since you'd have to destroy the component (or manually manage instances/states) to make it lose it's state.

I think the focus shouldn't be on more sophisticated components such as datepickers or typeaheads because frameworks typically don't provide them.

I would prefer to find a simpler use-case - a date-picker has a lot of irrelevant details regarding date logic.
A simple custom drop-down provides the same challenge. If instances of these were located on tabs, like you describe, the CSS work-around doesn't get you around this easily, since merely hiding the tab with the drop-down on it doesn't automatically cause the drop-down instance/state to reset.

The very easy work-around is to just use CSS to control visibility, however - the problem I've been trying to describe is a bit trickier in that regard, since you'd have to destroy the component (or manually manage instances/states) to make it lose it's state.

I think the safest scenario is the wizard scenario where each step is on a separate page (meaning has a different URL path). It's less likely then that the form state would be held in the component. But it shouldn't be forbidden, at the end of the day the project is about comparing approaches. Some of the steps should have state/data from the server and it should be required in the UX spec that that data is loaded only when the user gets to that step. Otherwise, it's possible that the user cancels the flow and so fetching that data from the beginning is not needed. As far as I know Vue allows you to reuse a component instance so that its state is not lost. But at some point I guess you would also need to reset the state so that after the flow is completed, if the user enters the flow again, they don't see the old state. Once the flow is started, it could be paused and later resumed. Once the user goes on a different page that is not part of the wizard a banner should be displayed on the page with some state of the wizard or some derived state, like the sum of something and it should also provide the ability of reentering the flow. The banner should also have the final submit button such that when the user clicks it, if there are steps with invalid fields (such as required fields with no value) the user is redirected to the first step with invalid fields. But also important: multiple rows with fields, with the ability of adding and removing rows.

Regarding forms and validation, here's my thoughts already, at least it should have some server side/client-side checks (before submitting) on the users email better than what we have.
https://github.com/sveltejs/realworld/issues/34
https://github.com/gothinkster/gcp-datastore-cloud-functions-realworld-example-app/issues/45


The test is not working since the URL is down

I am just forking this to add a feature, if it works I will submit a pull request.  However I just noticed the test is not working since this URL is not responding:
http://argonaut.healthintersections.com.au/open/metadata?_format=application/json
Is it possible to get that up and running again?

hi i am facing the same issues and the above URL now redirects to a completely new web address.


Android build error

Hi, I have a question, is it possible to add JavaVersion.VERSION_17 in build.gradle?
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
  }

My application won't build with 1_8:
Execution failed for task ':rn-bridge_react-native-geofencing:compileDebugKotlin'.
> Inconsistent JVM-target compatibility detected for tasks 'compileDebugJavaWithJavac' (1.8) and 'compileDebugKotlin' (17).

Maybe I can set something so that older libraries also work with this one?

@marekp97 Can you try setting the following in your build.gradle ?
kotlinOptions {     jvmTarget = "1.8" }

No, then I get an error:
Gradle DSL method not found: 'kotlinOptions()'
Possible causes:
Your project may be using a version of the Android Gradle plug-in that does not contain the method (e.g. 'testCompile' was added in 1.1.0).

My react-native version: 0.72

@marekp97 Can you try setting the same in library build.gradle as i was not able to reproduce the issue ?
kotlinOptions { jvmTarget = "1.8" }

@sriharshamadamanchi Yes, adding kotlinOptions { jvmTarget = "1.8" } in the library solves the problem too. Can you add it in build.gradle to the new version?

@marekp97 New version 1.0.3 is released with above change


Fix README code samples by replacing this with instance

I couldn't understand why the samples didn't want to work on my machine! After reading the API docs I realised they were wrong...

Which is the preferred way of using the API? If using this is preferred perhaps the other examples should be changed to also use it? Since the example which uses instance doesn't have any specific requirement for using instance instead of this it might only cause confusion?

@skaapgif I wouldn't say that there is a prefferred way. Both ways work. We need to show them both in the examples.
P.S.
Although, for stampit v3 we are thinking of removing the instance support from the first agument, and move it to the second argument of the init() functions. :) Sorry for much confusion.

I've changed those examples back to using this. I've kept my change in favour of using ES6 function declaration instead of ES5 since I think it's bad style to use both in the samp code sample (the anonymous function being declared as ES5 and getA being declared with ES6).
I haven't used stampit enough to run into every use case, but if there's no real advantage for using instance I would suggest that this becomes the official preferred way. Giving people two ways to do the same thing without any trade-offs or advantages just makes it harder to get started. If we want to show both ways of using it, it might be better to introduce that as a separate code sample so that each code sample in the readme only introduces one concept at a time. Just my 2c :+1:

it might be better to introduce that as a separate code sample so that each code sample in the readme only introduces one concept at a time.

100% agree. PR's are welcome. :)

Thank you Rudolf.


v-network-graph/force-layout dependency not found

Hi, really appreciate your amazing work!
I'm using Vue3 with Typescript and I can't reproduce this example about d3-force.
anyway, VSCode didn't show any error after importing v-network-graph/force-layout (the interface is reachable I guess), but the compilation failed when I run npm run serve.
here's the full error message:
 ERROR  Failed to compile with 1 error

This dependency was not found:

* v-network-graph/force-layout in ./node_modules/cache-loader/dist/cjs.js??ref--15-0!./node_modules/babel-loader/lib!./node_modules/ts-loader??ref--15-2!./node_modules/cache-loader/dist/cjs.js??ref--1-0!./node_modules/vue-loader-v16/dist??ref--1-1!./src/components/DiagramContainer.vue?vue&type=script&lang=ts

To install it, you can run: npm install --save v-network-graph/force-layout

thanks for reviewing this problem!

Hi @RainBoltz,
Thanks for your report.
In the package.json of v-network-graph, the specification scheme "Subpath exports" is used.
This does not seem to work well in some environments.
In the future, I may revise this way of specifying, but for now, please try the following:
import { ForceLayout } from "v-network-graph/lib/force-layout.es"

Best regards,

Hi @dash14,
Thanks for the fast reply!
When I use the code above:
import { ForceLayout } from "v-network-graph/lib/force-layout.es"

here comes another error:
Cannot find module 'v-network-graph/lib/force-layout.es' or its corresponding type declarations.ts(2307)

(I'm using Node14 + npm6 on MacBook)
can you provide any environment setting that can run the example successfully? that would be helpful!

Hi @RainBoltz,
Sorry for the late reply.
I was using Vite myself and had no problems, so I was not aware of the seriousness of this issue.
I created a new environment with vue-cli and was able to reproduce the error you reported, even with an alternative import statement.
Then, I have fundamentally reworked the configuration for importing, so please check using the new version. (v0.3.15)
Please import force-layout as follows:
import { ForceLayout } from "v-network-graph/lib/force-layout"

Hi @dash14 ,
Thx for the hotfix, really appreciate that! 💯


Cannot create multiple PKs (mixin .increments with .primary)

I want to create a table basing on following MySQL dump:
CREATE TABLE `my_table` (
  `cmdId` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `deviceId` char(16) NOT NULL,
  `fnNumber` int(10) unsigned DEFAULT NULL,
  `chNumber` int(10) unsigned DEFAULT NULL,
  `cmd` varchar(50) DEFAULT NULL,
  `cmdDate` datetime DEFAULT NULL,
  `delivered` tinyint(1) DEFAULT NULL,
  PRIMARY KEY (`cmdId`,`deviceId`),
  KEY `deviceId` (`deviceId`),
  CONSTRAINT `tblcommands_ibfk_1` FOREIGN KEY (`deviceId`) REFERENCES `second_table` (`deviceId`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

My knex looks like:
knex.schema.createTable('my_table', function(t) {
    t.primary(['cmdId', 'deviceId']);
    t.increments('cmdId');
    t.string('deviceId', 16).notNullable().references('second_table.deviceId');
    t.integer('fnNumber').unsigned();
    t.integer('chNumber').unsigned();
    t.string('cmd96', 50);
    t.dateTime('cmdDate');
    t.boolean('delivered');
});

However there is a problem with primary keys. I get following error:
Error: Multiple primary key defined

I assume that increments method already creates PK and primary method creates another one which causes an error.
Is it possible to achieve this format of table ?

I have a similar issue -- I want to use .increments() without it being a primary key.  In my case it is for performance reasons.  I want to create the table with no indexes (which means no primary key), insert many rows into it, and then add an index on the autoincrement column.  This is more performant, and in fact is recommended by the Postgres documentation (see http://www.postgresql.org/docs/9.4/static/populate.html#POPULATE-RM-INDEXES), but currently seems impossible to do with knex.

I also seem to run into similar issue. I am not able to create a table that has:
knex.schema.createTable("numeric_table", function (table) {
    table.integer("integer_key").primary;

   // Both increments & bigIncrements tries to create primary key.
    table.increments("increment_key");
    table.bigIncrements("big_increment_key");
});

Same issue here .increments() tries to define a primary key

You can use a raw query to add an increments columns without its primary key:
exports.up = function (knex) {
  return Promise.all([
    knex.raw('alter table "my_table" add column "my_seq" bigserial'),
  ]);
};

exports.down = (knex) => {
  return Promise.all([
    knex.schema.table('my_table', (t) => {
      t.dropColumn('my_seq');
    }),
  ]);
};

Or you can create de autoincrement column with
table.specificType('myid','serial');

(only for Postgresql)
But I think is much better table.increments()  will create the PK only if i manually specify that with table.increments().primary()

Why not leave
increments: 'serial'
instead of
increments: 'serial primary key'
Whats the problem with that?

I still get the same error.
IMHO .increments shouldn't create PK.
Any news on this issue?

Agreed -- while it is certainly possible to work around this issue in various ways, it is rather bizarre that the API doesn't have first-class support for creating an auto-increment column without making it a primary key.
With that said, I imagine this hasn't been fixed yet though because to correct this in the most sensical way would be a breaking change, and so it would have to be part of a major version bump.

@zacronos
The thing is if we use .primary() on a columns when creating a table, the result would be a separate query for creating the table, and another alter table query to define the primary keys.
I think in MySQL (or perhaps other DBMSs too), you can not have a auto_incremement field without being PK.
So, knex creates the table with the primary key, and then it can not just alter it to define two primary keys since the table already has one.
If we could fix this, maybe .increments still create PK but allows other columns to be PK as well all in one create table query, so we probably wouldn't need a major version bump.
Or we can add another column type for this and leave .increments as is to not to break backward compatibility.

@amir-s: well that explains why knex behaves as it does -- it is apparently attempting to have behavior that is equivalent across the different supported DBMSs.  I don't particularly like that, but at least it doesn't seem bizarre now.
The problem with your suggestion is that by definition you can't have multiple primary keys on a table.  (You can have 1 composite PK on multiple columns, but that is very different from having 2 single-column PKs.)
So if .increments creates a PK, then it is impossible to allow other columns to also be marked as PK.  It would be possible to create an option that can be passed to .increments to disable the primary key behavior on Postgres and any other DBMS that supports such behavior.  Perhaps that's the best solution, as it doesn't break backward compatibility and it also doesn't break cross-DBMS compatibility.  I still don't like that as well as changing the default behavior on Postgres so that .increments doesn't also make it a PK, but it would be a more easily accepted PR.
If anyone wants to submit a PR along those lines, I'd argue in its favor.  :-)

@zacronos  Sorry, by "multiple PKs" I meant "one PK on multiple columns".

In agreement with all the comments above.  This behavior was unexpected when trying to create a composite primary key as well as a non-key auto-incrementing column.  It would be great to see this implemented.

I'm running into this issue as well, but in the case of using Postgres and using serial fields as foreign keys - the knex implementation of a Postgres serial field is increments() and this make them primary keys by default. I want to be able to build sqlite3 as well as postgres, so using a raw knex query would confine me to either or. Any workaround suggestions?

This thread hasn't gotten much attention in a while.  I'd like to reiterate what I think is an ideal, backward-compatible solution (which can thus be part of any minor release): add a new option to .increments(), maybe primaryKey: false, which (for DBMSs where this is possible) disables the primary key part of its functionality.
This is entirely backward compatible since .increments() retains its default behavior.

Same issue here. Have to use raw query to avoid bigIncrements to attempt to create another primary key.

Workaround:
table.bigincrements();
table.biginteger('other').notNullable();
table.dropPrimary();
table.primary(['id', 'other']);

If I understand the previous investigation on this topic correctly then pressumably knex forces a primary key strictly because some DBs (ie MySQL) cannot create serials without it being a primary key? If such is the case, I wouldn't worry too much about backwards compatibility when it comes to Postgres.
A MySQL user would then expect it to be a primary.
A Postgres user would not. (Which is evident above)
For this reason I think it's pretty safe to made an adjustment in Postgres to not force primary key, and add it to the changelog. Not as a patch, but for next major version.

For this reason I think it's pretty safe to made an adjustment in Postgres to not force primary key, and add it to the changelog. Not as a patch, but for next major version.

I know tens of people who has always written their migrations just by writing only table.bigincrements('id') without .primary() also for postgresql, because it has been always working like that.
I though there was an extra option, which should be used to tell that the primary key should not be created, but looks like it is not there. At least I didn't find anything for postgres / mysql implementations about skipping primary key creation.
This would be major backwards compatibility breaking change on migrations that I would hate to see this happening. If we want to keep up patching this old migration API we first need to add versioning support for it to prevent all the people from fixing their old migrations on every knex version (those changes in migration code is really hard to verify working exactly the same with automatic tests so it is very vulnerable part in knex's users' code).

Any news on this?

This thread hasn't gotten much attention in a while. I'd like to reiterate what I think is an ideal, backward-compatible solution (which can thus be part of any minor release): add a new option to .increments(), maybe primaryKey: false, which (for DBMSs where this is possible) disables the primary key part of its functionality.
This is entirely backward compatible since .increments() retains its default behavior.

Can we use increments like this? any update?

How is that going ? it's really a  pain, especially in MSSQL, PK constrain is not named by default but like "PK__requests__DD771E3CC0CD0A5E"  so I can't even drop it and create PK somehwere else.
I've trued to specify name for constrain but it does not work for increments()

Still nothing on that ?

Would very much like the optional parameter in .increments as well! Raw queries could obviously work, but it is annoying for those who run multiple different DB's (e.g. mariadb for production, sqlite for testing). Any updates on this? There seems to be a PR already made, but it kinda went silent there?

I again second that, I already needed that 3 time in single project.

Same issue here, having an extra parameter to disable PK seams reasonable.

Similar to #2896 you can use for MySQL:
t.primary(["cmdId", "deviceId"]);
t.specificType("cmdId", "int(10) unsigned AUTO_INCREMENT").notNullable();
t.string('deviceId', 16).notNullable().references('second_table.deviceId');

I found this way to resolve this, I don't know if is the best way, but it worked well:
`this.schema.createTable(this.tableName, (table) => {
table.integer('id').unsigned().notNullable().unique()
table.string('path')
table.enum('type', ['CPF', 'RG'])
table.integer('user_id').unsigned().notNullable()
table.foreign('user_id').references('id').inTable('users')
table.primary(['id', 'user_id'])
  table.timestamps(true, true)
})
this.schema.alterTable(this.tableName, (table) => {
  table.increments('id', { primaryKey: false }).alter()
})`

I found this way to resolve this, I don't know if is the best way, but it worked well:
`this.schema.createTable(this.tableName, (table) => {
table.integer('id').unsigned().notNullable().unique()
table.string('path')
table.enum('type', ['CPF', 'RG'])
table.integer('user_id').unsigned().notNullable()
table.foreign('user_id').references('id').inTable('users')
table.primary(['id', 'user_id'])
table.timestamps(true, true)
})
this.schema.alterTable(this.tableName, (table) => {
table.increments('id', { primaryKey: false }).alter()
})`

I found this way to resolve this, I don't know if is the best way, but it worked well:
this.schema.createTable(this.tableName, (table) => {
table.integer('id').unsigned().notNullable().unique()
table.string('path')
table.enum('type', ['CPF', 'RG'])
table.integer('user_id').unsigned().notNullable()
table.foreign('user_id').references('id').inTable('users')
table.primary(['id', 'user_id'])

table.timestamps(true, true)
})
this.schema.alterTable(this.tableName, (table) => {
table.increments('id', { primaryKey: false }).alter()
})

I found this way to resolve this, I don't know if is the best way, but it worked well:
knex.schema.createTable(this.tableName, (table) => {
    table.integer('id').unsigned().notNullable().unique()
    table.integer('user_id').unsigned().notNullable()
    table.foreign('user_id').references('id').inTable('users')
    table.primary(['id', 'user_id'])

    table.timestamps(true, true)
    })
    knex.schema.alterTable(this.tableName, (table) => {
        table.increments('id', { primaryKey: false }).alter()
})

Any news from this? I am using Knex 0.95.14 and I still face the same problem.

Any news from this? I am using Knex 0.95.14 and I still face the same problem.
Try setting your primary key like this, that's what worked for me and it doesn't seem wrong

knex.schema.createTable('table_name', (table) => {
      table.integer('id').unsigned().notNullable().unique()
      table.integer('user_id').unsigned().references('id').inTable('users')
      table.primary(['id', 'user_id'])
    })
    knex.schema.alterTable(this.tableName, (table) => {
      table.increments('id', { primaryKey: false }).alter()
    })
}

Any news from this? I am using Knex 0.95.14 and I still face the same problem.

I raise the priority and take the task. I will try to take a look quickly.

Released in 1.0.1.


cwd in Task

Hi,
	"debugger_tasks": [ 		{ 			"name": "Compile", 			"shell_cmd": "cmake --build build/", 			"file_regex": "$cc", 			"cwd":"${project_path}", 		}, 	],
is something like this not possible? I get this error init() got an unexpected keyword argument 'cwd'.
I need the build command to go off in the project root, but sublime is running it from the folder that contains the current file. e.g
project/source instead of project. So I have to keep switching files to run the debugger

Its weirdly called working_dir see https://www.sublimetext.com/docs/build_systems.html

Thank you! Also sorry I thought that was controlled by this project


Subscriptions

I have a problem creating custom subscription.
I've created custom resolver (to create a resource) and I would like to add custom subscription for that.
It's not clear for me if I should do anything beside defining that in graphql schema?
Do I need to create custom resolver to handle that? Is that magically handled? Is there a chance to get some documentation or example for it?

@maoosi I've managed to solve my problem I would be to happy to add a "how to" to your docs if you just point me into right direction.

Hey @adamszeptycki, happy to hear that you've solved your problem.
There is a section in the documentation dedicated to "Extending the API" (using custom resolvers) at prisma-appsync.vercel.app/guides/extending-api.
Feel free to open a PR and contribute to the docs if you feel like something is missing or could be explained better.


Postgres recovery issue, possibly caused by lack of garbage collection on jobs listing

A test cluster produced a 12 hour long Postgres degradation alert, via monitoring of the status app. This appeared to coincide with an earlier ramp up to 100% CPU usage (but low load) on one node, which was traced to the flynn-host daemon and the flynn-scheduler container. That scheduler job was listed as down for a long time (via flynn ps -a) with no attempt to replace it visible as it normally would be on that list.
Running flynn-host collect-debug-info on that node resulted in a huge load spike on the wedged node, an OOM partway through the collection, a subsequent drop in CPU usage, and the a clearing of the pg status alert. This all coincided relatively closely, making me think the symptoms are related despite broadly different start times.
Also probably salient is that there were roughly 80K of terminated jobs (via flynn-host ps -a), from an old flapping job which had (a while before this) been turned off.
https://botbot.me/freenode/flynn/2016-09-21/?msg=73387396&page=1 has more of the conversation around debugging it, including recovered logs and the process list.

Additional note: the lack of status alert on the wedging of the scheduler is potentially more problematic, in my book. We should have known it was having issues back when they started, not after they cascaded.

Hrm, okay it appears I've misinterpreted the scheduler stuff. It looks like there's supposed to be only one, not two like I'm seeing via flynn -a controller ps --all:
ID                                                 TYPE       STATE  CREATED      RELEASE
ip1010036184-e05fa18c-606d-4af1-97be-d8940c3bc8c6  scheduler  up     2 weeks ago  0fca8fb7-2ee0-43be-8c63-586e8fe972c2
ip1010036184-1ba1eaf8-f2df-4b8c-9f14-ca577ddf9809  web        up     2 weeks ago  0fca8fb7-2ee0-43be-8c63-586e8fe972c2
ip1010036183-332d8377-a347-4150-ae2d-13588664a38f  scheduler  up     2 weeks ago  0fca8fb7-2ee0-43be-8c63-586e8fe972c2
ip1010036185-102abd33-acad-43c4-9ac7-cbfe87bcd986  scheduler  down   2 weeks ago  0fca8fb7-2ee0-43be-8c63-586e8fe972c2
ip1010036183-4739c891-10a8-471d-a452-a784d94413c0  worker     up     2 weeks ago  0fca8fb7-2ee0-43be-8c63-586e8fe972c2
ip1010036183-1ce93699-efdb-4c52-9c01-cf0d0a6dde6f  web        up     2 weeks ago  0fca8fb7-2ee0-43be-8c63-586e8fe972c2
ip1010036184-53b7774f-e1bd-4f61-b400-33e0fd360312  worker     up     2 weeks ago  0fca8fb7-2ee0-43be-8c63-586e8fe972c2
ip1010036183-871bdcca-442f-4fbc-be4b-237c8dd64243  run        down   6 days ago   4f004ffb-832b-4a8d-a8de-3f53b70205ad
ip1010036184-ea0ebbb6-5240-4db3-9800-f24f3ff753e2  run        down   6 days ago   4f004ffb-832b-4a8d-a8de-3f53b70205ad
ip1010036185-81ace49d-456c-45b5-89c1-105451fad3d9  run        down   6 days ago   4f004ffb-832b-4a8d-a8de-3f53b70205ad

Ah, no: I was right, that's an omni job. So: the third scheduler is still down, not up like I thought. :-/

Our current thinking here is for flynn-host to only track the last N stopped jobs, and I am going to run some benchmarks to determine an appropriate value for N.
I think the subsequent issues (a scheduler being down, postgres becoming unhealthy etc.) were all due to the high load caused by the schedulers and flynn-hosts stuck in a job sync feedback loop.

Fixed in #3767.


descriptionClassName not being applied

Hello,
When I pass descriptionClassName to the toastOptions object, it does not get applied to the description text. I have this in my nuxt plugin
import { Toaster } from "vue-sonner";

export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.vueApp.component("Toaster", {
    setup(props, ctx) {
      return () =>
        h(Toaster, {
          toastOptions: {
            className: "!bg-background !text-foreground !border-border",
            descriptionClassName: "!text-muted-foreground",
          },
          ...props,
          ...ctx.attrs,
        });
    },
  });
});

The className gets applied but when I check the browser elements, for the description, I see undefined

@BayBreezy
it should be fixed in new release


docs: ADR for the DID module

there are still the modification of services to add

I'm preparing a few changes here, I'll commit them before merging

I went ahead and moved the external links from headings to the following text per best practice

Following all the (very good) comments and suggestions, I made a major rework of the adr, extracting what is specification from what is documentation.
I am confident that this version is more mature


Allow POST, HEAD and OPTIONS requests

Hi,
I've made an update to extend the proxy functionality to handle POST requests.
Currently, I'm working on Proxying a 3rd party API so that there's no direct IP connection between the user's browser and their server. However, the API requires POST requests to send data to a remote server.
To address this, I also added support for handling HEAD and OPTIONS requests to manage CORS and allowed-origin headers, which are essential when dealing with POST and XHR requests from the browser.
I'm not entirely sure if this fits within the scope of the project, so if it's not aligned with the project's goals, feel free to reject the changes. No hard feelings!
Best,
Lukas

Hi,
I think you are right and it's better to create new "Proxy client" that will proxy all requests.
Do you plan to do it on your own?
As an option I can add this task to our backlog.

i merged it into main on my fork. along with adding wildcard (regex) file support. - so in a sense that already exists.


Transhuman Coin

TRANSHUMAN COIN Token submission for iotube
Please read the token submission guide here: https://docs.iotube.org/introduction/token-submission
Team / Developer name
CEO & Founder: Dr. Charles Awuzie - www.facebook.com/reformed.charles.awuzie | https://www.linkedin.com/in/drcharlesawuzie
Co-founder: Peter Xing - https://www.linkedin.com/in/peter-xing
Co-founder: Alyse Sue - https://www.linkedin.com/in/alysesue
...
Token Symbol
THC
...
Token Decimals
9
...
Token Name in full
TRANSHUMAN COIN
...
Link to the token icon
https://transhumancoin.finance/thclogo.jpg
Short description of your project
We started as a meme coin for the Transhumanism movement - a community of over 2 million Scientists and Technologists around the world. Then we started building utilities. We built P2P Exchange - p2p.valid.finance and also in the process of announcing our DeFi trading tool platform - valid.finance which is currently registered in the UK.
Who are we? Transhuman Coin is a Research oriented BEP20 token merging Biotech & Artificial Intelligence in the metaverse with the aims of using technology to solve ageing, diseases and improve longevity.
Transhumanism is the ideology of enhancing human life through Science & Tech. As a project dedicated to Human Enhancement, we fund Advanced BioTech Projects, Assistive Technologies, Research on Anti Ageing etc. THC is also the native token of valid.finance and p2p.valid.finance
We are building Decentralized Labs in the metaverse & our E-shop will accept our token in exchange for medical supplies. Our Smart Contract is [audited by Techrate. https://github.com/TechRate/Smart-Contract-Audits/blob/main/November/Transhuman Coin Full Smart Contract Security Audit.pdf
WE ARE BUILDING A HEALTH dAPP on [IOTEX BLOCKCHAIN.https://community.iotex.io/t/accepted-transhumancoin/8941
Transhuman Coin is the first and only token dedicated to Transhumanism and fastly becoming the major currency of transaction in Transhumanism communities globally. We are governed by a Board of Scientific Advisors who meet regularly to provide leadership for the project. You too can join this board if you have the right amount of THC required."
What is the blockchain (source blockchain) that your token is issued on

[ ] Binance Smart Chain

What blockchains (destination blockchain) would you like your token is bridged to

[ ] IoTeX

(Please check https://docs.iotube.org/introduction/token-submission#integration-fee for integration fees of different blockchains)
Token native contract address explorer link
Address: https://bscscan.com/address/0x56083560594E314b5cDd1680eC6a493bb851BBd8
Your project websites

https://www.transhumancoin.finance

Your social channels

Telegram: https://t.me/buytranshumancoin
Twitter: htpps://www.twitter.com/transhumancoin
Facebook: https://www.facebook.com/transhumancoin

Verification of the token
Please provide the verification of your token in one of the following ways.

[ www.transhumancoin.finance - you will find the token address and cmc page] Token address on your website. Please specify the link.
[ ] CMC / Coingecko profile link with token contract address and link to website/social - https://coinmarketcap.com/currencies/transhuman-coin/
https://www.coingecko.com/en/coins/transhuman-coin

Send test tokens
Please send a few test tokens ($1-$10 worth) to our wallet address: 0x571e603e3B5c82Bd40998C538603dF4fb42bB051.
PAID:  https://bscscan.com/tx/0x1edb95ffd060e9a7493631a801dfd587e315cf631fa50663e07c6ff00ac87115
Integration fee
Please send the payment to 0x571e603e3B5c82Bd40998C538603dF4fb42bB051 or io12u0xq03mtjpt6sye33fcvq7lf76zhvz3yvt8q0 and post your txn link here.
PAID:   https://bscscan.com/tx/0x3c3392856e583be7c8cdce4767ccc1f50525275ffaea4787dbc215ef9e688be1

ioTube does not support tax-based token yet. That requires additional work and time. (We are still investigating the feasibility now.)

Hi guo, thanks for the response. What if iotube's contract address is whitelisted by us, that way transactions done on iotube are tax free? this has worked in our other integrations - including cex and swft blockchain. we are a project of interest for Raullen and it is important that we bridge to iotex asap. thanks once again Guo.

also, please note that the crosschain token on iotex will not have tax feature like on BSC.

Yes, we understand that the crosschain token on iotex will not have the current tax feature.
Some interesting update: We are being featured in the CMC KillerwhalesTV show and one of our core pitch includes our iotex proposal. We have mentioned that we are bridging using iotube to the organisers and will like to know the time frame for the bridge?
Looking forward to a THC on iotex via iotube. Thanks!

@guo Here is the CTHC generated on BSC: https://bscscan.com/address/0x8dfb1099c53f634becf3c98ae19eb1baa1b37d43

Thanks @guo .

@gemsbokgroup have you whitelisted this address?

Yes - now whitelisted on tx: https://bscscan.com/tx/0x60fe1d1080c5911669f1c5bdcadd9056523debf8cd0e7b951470707965025fb5

deployed crosschain token on iotex: 0xB4CBD308e879C0C3a3a996ad6c7576B123a506f4.

@gemsbokgroup could you also whitelist https://bscscan.com/address/0x2a26fede01bfa03e65cd3c68f421cab83648391a#code, which will enable the direct deposit of THC? After that, you may try on https://web-iotube-org-pr-183.onrender.com/tube by yourself. Be aware that there are fees when you transfer from IoTeX to BSC.

Thanks. The address is now whitelisted - https://bscscan.com/tx/0x2fb93d2b9926cf69dc45fb1889e0e434597cb85b12a2bc64705137c4005ab756 . And i successfully swapped 100000 THC to CTHC. Thanks.

you can try to bridge token's to iotex too.
I have tested. Both THC and CTHC can be bridged to iotex now. I am going to
merge the front end change if you don't see any issues.
On Sun, Jun 18, 2023 at 4:54 AM Charles @.***> wrote:

Thanks. The address is now whitelisted -
https://bscscan.com/tx/0x2fb93d2b9926cf69dc45fb1889e0e434597cb85b12a2bc64705137c4005ab756
. And i successfully swapped 100000 THC to CTHC. Thanks.
—
Reply to this email directly, view it on GitHub
https://github.com/iotubeproject/ioTube/issues/183#issuecomment-1596116587,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADNOJPT5OYJBOQAHTW2IMLXL3T7NANCNFSM6AAAAAAYMK4SS4
.
You are receiving this because you were mentioned.Message ID:
@.***>

launched on ioTube now. Closing task.

Thanks @guo . We could connect further on telegram - t.me/gemsbokgroup
Looking forward to more collaborations in the IoTex ecosystem. Cheers.


Stop using operatorsAliases from sequelize

When we init the app, there is a warning from Sequelize:
sequelize deprecated String based operators are now deprecated. Please use Symbol based operators for better security, read more at http://docs.sequelizejs.com/manual/tutorial/querying.html#operators node_modules/sequelize/lib/sequelize.js:242:13

More info about operators aliases:
http://docs.sequelizejs.com/manual/tutorial/querying.html#operators
To fix that on the short term, we need to pass the list of the operatorsAliases we want to use as sequelize configuration.
To fix that and be future proof, we would need to:

[x] add operatorsAliases: false to sequelize configuration
[x] stop using operators aliases in the code base:

[x] $eq -> [Op.eq]
[x] $ne -> [Op.ne]
[x] $gte -> [Op.gte]
[x] $gt -> [Op.gt]
[x] $lte -> [Op.lte]
[x] $lt -> [Op.lt]
[x] $in -> [Op.in]
[x] $like -> [Op.like]
[x] $contains -> [Op.contains]
[x] $or -> [Op.or]
[x] $col -> [Op.col]
[x] $notIn -> [Op.notIn]
[x] $and -> [Op.and]
[x] $not -> [Op.not]
[x] $iLike -> [Op.iLike]
[x] $overlap -> [Op.overlap]

[x] wait for fix in dataloader-sequelize
[ ] look again at _merge in collectives.getTransactions

Our dependency dataloader-sequelize is not compatible with the changes.
PR opened there:
https://github.com/mickhansen/dataloader-sequelize/pull/52

Pass tests.


Make browser cache identical image with different aws s3 presigned url?

Feature
Currently imagine sends a 307 to the actual presigned URL, which is regenerated every time (i.e. also on browser refresh) even when the URL is still valid, i.e. not expired. This creates lots of HTTP request especially ob overview pages that uses presigned image URL for avatar items
URL References

https://stackoverflow.com/questions/53205295/how-to-make-browser-cache-identical-image-with-different-aws-s3-presigned-url
https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

closing since we now have both server side url cache as well as browser caching via http headers


UX : Fonts are difficult to read

@sumathi-thirumani-aot  @JHarrietha-AOT seeing this is an early ticket - have addressed this one sufficiently through some of the other UX assurance and tech debt work we've undertaken? Please close if it is outdated

@mpilchar this has not been addressed, this will be larger ticket.
It would come into play POST MVP, we had it outlined in our feedback from training and I have briefly talked about it with @nkan-aot  who said it would be a larger undertaking as I think we should look at increasing most elements on the page based off of user feedback. We discovered with some user input that what feels like a comfortable size is when people are zoomed into about 125% on chrome.


Range doesn't work in SQL server in WITH queries

In queries that have with,
select count(*) from (
  with a as (select * from ...),
  select * from ...
) as temp

doesn't work in SQL Server because (annoyingly) it doesn't support it in subqueries. One solution is that when with is detect in the subquery, it could merge it and be run like this:
with a as (select * from ...),
temp as (select * from ...)
select count(*) from temp

But I don't know if it's a bug of major notoriety. My workaround is avoiding range and implementing my own for my complex queries (which are a few).

Rewriting the queries like that seems scary. Will that work in all possible cases? I'd rather not fix this bug because it can have unexpected consequences with some complex queries I can't even think of.

It will definitely not work if someone names a query they have temp, which is actually rather likely.


step-ca: fix flaky test parallelism

step-ca seems to run some tests using the global localhost interface inside the build sandbox, and on big x86_64-linux machines we've observed they occasionally fail.
This restricts the tests to one core.
Fixes failure [hydra, local:fail, local:flaky-succeess] introduced in #211596.
Description of changes

Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 212623 run on x86_64-linux 1

1 package built:

step-ca

With this change, I can build it locally again :)


Stop using Travis CI

As documented in https://github.com/exercism/purescript/issues/126 Exercism is moving from Travis to GitHub Actions. Setting up CI under GitHub Actions has been implemented in another commit.
Here we remove the .travis.yml file to stop building on Travis CI. Note that this has been broken since the exercises were migrated into concept and practice categories.

Great!


[Do not merge] Add govspeak content to travel advice

Part of this story https://trello.com/c/u8ECSvIC/411-send-govspeak-as-well-as-html-in-travel-advice-publisher and branched from https://github.com/alphagov/govuk-content-schemas/tree/travel_advice this adds a new field type multiple_content_types to accommodate multiple formats of content ie. html and govspeak.
Currently awaiting this #139 to be merged.

Needs a rebase.


Increase request_with_flags timeout deadline

Makes it equal to that of (very similar) test request_with_payload.c, and allows work-in-progress new transport work to pass.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok to test.

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok to test.

LGTM


[ZDF]Videos are rotated

I downloaded 2 videos from zdf.de using youtube-dl. But they are 180 degrees rotated. It works fine last week, so they changed it probably this week. youtube-dl needs to rotate the videos at 180 degrees after downloading  to make them look correct.

I had seen this is a bug in my video player. Other players works without problems. Closing this now. Sorry.


MacOS 11_0 ARM wheel is missing image.so

🐛 Describe the bug
The MacOS 11_0 ARM wheel for release 0.11.2 does not provide the image.so shared library (this applies to both Python 3.8 and Python 3.9).
Thus, when importing torchvision on an Apple Silicon Mac running macOS Monterey, the following warning is raised:
UserWarning: Failed to load image Python extension:

Versions
PyTorch version: 1.10.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.1 (arm64)
GCC version: Could not collect
Clang version: 13.0.0 (clang-13<IP_ADDRESS>)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.9 (main, Dec 29 2021, 16:03:39)  [Clang 13.0.0 (clang-13<IP_ADDRESS>)] (64-bit runtime)
Python platform: macOS-12.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.5
[pip3] pytorch-lightning==1.5.7
[pip3] torch==1.10.1
[pip3] torchmetrics==0.6.2
[pip3] torchvision==0.11.2
[conda] Could not collect

Thanks for the report @borchero . Our of curiosity do you know if 0.11.1 was working properly on M1?
Perhaps this is something that @malfet can help with?

Seems that there is no torchvision 0.11.1 wheel released on macOS M1.

Anyone know a workaround for this? I tried downgrading versions and didn't have any luck

Should be solved by 0.11.3 release, see https://pypi.org/project/torchvision/

The warning seems to be still there. When I use pip to install torch=1.10.2, torchvision=0.11.3, the import statement
import torchvision

throws out the similar warning:
/Users/alanyoung/Documents/Codes/Kaggle/ClassifyLeaves/venv/lib/python3.9/site-packages/torchvision/io/image.py:11: UserWarning: Failed to load image Python extension: dlopen(/Users/alanyoung/Documents/Codes/Kaggle/ClassifyLeaves/venv/lib/python3.9/site-packages/torchvision/image.so, 0x0006): Library not loaded: @rpath/libpng16.16.dylib

I use MacBook Pro with M1 Max and there is not a image.so in torchvision directory.🤔
I notice that it has been talked in https://discuss.pytorch.org/t/failed-to-load-image-python-extension-could-not-find-module/140278/21 by Andrade.
@malfet Could you please check this?

@alanyoungCN thank you for reporting, but as you can see from the signature, issue is a bit different: image.so is present, but missing one of the dependent libraries. conda install libpng would undoubtedly solve this

@malfet Sorry for the title, I mention it in https://github.com/pytorch/vision/issues/5413#issuecomment-1039234856. But I use pip to install torch and torchvision, I can't install libpng by pip.
Besides, when I install libpng in conda base env, the warning becomes Library not loaded: @rpath/libjpeg.9.dylib. It's very confusing.
cc plz🙏

@malfet
It works, thank you.
For now, the solution is installing the missing dylib by conda install libpng and conda install jpeg in conda base env, and it seems every python env will be okay.
But there is a little remaining question, how to install them in a pip-only environment?

@alanyoungCN It depends on the environment/operating system etc. You can install the libraries separately (for example using apt if you are on a debian system). Conda takes care of that.

@dimart
I do have installed it by brew install libpng, but it locates in /opt/homebrew/Cellar/libpng/ which is not in the @rpath lists(please see the full warning in https://github.com/pytorch/vision/issues/5413#issuecomment-1039234856), therefore leading the Library not loaded: @rpath/libpng16.16.dylib warning.
I wonder if you can bundle them all in .whl file, it may work.


Remove Deployment script PostDeployment

Current State

Once deployment scripts have completed, the deployment script resource is left behind in the RG.

Limitations

None present.

Request

Include script in PostDeployment.ps1 to delete script resource and clean up.

The script retention period is something we can configure within the ARM template itself (scroll to bottom to see the Microsoft.Resources/deploymentScripts resource).
For our reference, the two properties which influence this include:

cleanupPreference: Clean up preference when the script execution gets in a terminal state.
retentionInterval: The time interval that a script resource will be retained and after which will be expired and deleted.

Clean up deployment script resources for more information.
The script currently has retentionInterval set to PT4H (i.e. 4 hours), this was intended to help debug issues during testing but re-reading the documentation, it appears I'm not using this property correctly as it only appears to kick-in when cleanupPreference is set to OnExpiration (which it currently is not).
Suggested Change:

We remove retentionInterval and replace it with cleanupPreference, setting the value to On Success. This should delete the script resource automatically when the script execution is successful. If it fails, should leave it behind for debugging purposes.


When running hello firewall prompt pupping up

Since crank appears to download everything into unique temp folder, and compile code there, it constantly ask for permissions to run hello.exe from unique location each time. See below.
C:\users\user\appdata\local\temp\benchmarks-agent\benchmarks-server-24280\fye32qrb.n4c\crank\samples\hello\published\hello.exe

Maybe docs can be expanded to provide solution for that. Or crank itself should open firewall rules for benchmarks.

I didn't find a way to prevent that. Each app is built in a different temporary folder, so it happen for every run on Windows 10 (doesn't happen for me on Windows Server). Each time we hit "Allow" it create a rule. However not clicking it doesn't seem to have any effect on the run.
Not sure if it's possible to allow any application in the C:\users\user\appdata\local\temp\benchmarks-agent folder. As even the app names will vary from app to app.

I can't repro this on my local machine. Can you try adding this C:\users\[USER]\appdata\local\temp\benchmarks-agent folder in the Windows Defender exclusions?

I added some documentation about it (see getting-started in this PR https://github.com/dotnet/crank/pull/172)


sentry-slack sentry 8.2.2

Hi im trying to install sentry slack for sentry 8.2.2 but i cant see that sentry slack pops up in the Integrations list.

I have the same issue with sentry 8.2.3

Can you you provide any more information? When Sentry starts up, it should dump out an error while loading the plugin if that's the case. It'd be like:
Failed to load plugin: 'slack'

With a stacktrace.

There is no mention of slack when sentry starts:
root@web01:/srv/sentry# /srv/sentry/venv/bin/sentry --config=/srv/sentry/sentry.conf.py start Running service: 'http' *** Starting uWSGI 2.0.12 (64bit) on [Wed Mar 16 16:36:43 2016] *** compiled with version: 4.7.2 on 16 March 2016 09:32:25 os: Linux-3.4.4 #1 SMP Wed Jul 18 01:32:13 CEST 2012 nodename: web01 machine: x86_64 clock source: unix pcre jit disabled detected number of CPU cores: 1 current working directory: /srv/sentry detected binary path: /srv/sentry/venv/bin/uwsgi uWSGI running as root, you can use --uid/--gid/--chroot options *** WARNING: you are running uWSGI as root !!! (use the --uid flag) *** your processes number limit is 23416 your memory page size is 4096 bytes detected max file descriptor number: 1024 lock engine: pthread robust mutexes thunder lock: enabled uwsgi socket 0 bound to TCP address <IP_ADDRESS>:9000 fd 4 Python version: 2.7.3 (default, Mar 13 2014, 11:26:58)  [GCC 4.7.2] Set PythonHome to /srv/sentry/venv Python main interpreter initialized at 0xe2ee60 python threads support enabled your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds setting request body buffering size to 65536 bytes mapped 1441536 bytes (1407 KB) for 8 cores *** Operational MODE: preforking+threaded *** spawned uWSGI master process (pid: 10166) spawned uWSGI worker 1 (pid: 10173, cores: 4) spawned uWSGI worker 2 (pid: 10174, cores: 4) WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0xe2ee60 pid: 10173 (default app) WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0xe2ee60 pid: 10174 (default app)

What if you do:
$ sentry plugins list

There is no output:
(venv)root@web01:/srv/sentry# /srv/sentry/venv/bin/sentry --config=/srv/sentry/sentry.conf.py plugins list
(venv)root@web01:/srv/sentry#

Then it's not installed. :)

pip freeze lists sentry-slack==0.5.0 so the package is installed. I've followed instructions and ran pip install sentry-slack. Is there anything more to do? Maybe add it to the INSTALLED_APPS?

Are you running pip from within the same virtualenv? In your case, it'd be /srv/sentry/venv/bin/pip

Yes, I've double checked and /srv/sentry/venv/bin/pip freeze returns the same list.

Hey @dblenkus, can you run this and print the output?
>>> from pkg_resources import iter_entry_points
>>> list(iter_entry_points('sentry.plugins'))
[...]

root@web01:~# source /srv/sentry/venv/bin/activate
(venv)root@web01:~# python
Python 2.7.3 (default, Jan  2 2013, 13:56:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg_resources import iter_entry_points
>>> list(iter_entry_points('sentry.plugins'))
[]

It sounds like your virtualenv or setuptools is broken. Try to reinitialize the venv, update setuptools etc. This is not an issue with sentry or the plugin.

Thanks for pointing this out! It works perfect after updating pip and recreating virtualenv.


Change usages of Kokkos::View<...> to use aliases

This change is in response to some of the feedback we received in the code review to improve readability.  The various fixed and dynamic sized Views are now defined in types.hpp.  Const versions of the types are obtained by using existing definitions on the main type, e.g. View1D::const_type.
Note another small change: I have modified how we register tests with CTest.  Before, CTest saw our unit test file as one test with no indication of which test failed, now it registers every test individually using more idiomatic GTest-CMake functions.  Running with the unit test executable directly is unchanged.
These changes are purely cosmetic, but touch many lines of code.

CppCheck has identified a several things to be fixed, do you want to take care of those before merging?

CppCheck has identified a several things to be fixed, do you want to take care of those before merging?

Both CppCheck and Clang-Tidy are really noisy right now.  Looking at the CppCheck output on here, none of the complaints seem to be about our code, but I may be missing some.  I'm going to tweak the settings on both of these in the near future to make them more useful and do a large-scale cleanup based on it.  Do you see any specific CppCheck complaints that you want addressed?

This change is in response to some of the feedback we received in the code review to improve readability. The various fixed and dynamic sized Views are now defined in types.hpp. Const versions of the types are obtained by using existing definitions on the main type, e.g. View1D::const_type.

Totally agree with this change - it was much needed to collate and define the rather verbose types used in OpenTurbine in a single location, which makes things much more maintainable.

Note another small change: I have modified how we register tests with CTest. Before, CTest saw our unit test file as one test with no indication of which test failed, now it registers every test individually using more idiomatic GTest-CMake functions. Running with the unit test executable directly is unchanged.

Not sure I follow the motivation here, an example would have been helpful (before and after). Anyways, this PR should have been split into two imo, just to keep the lines of change more manageable.


ParentalControl/Firewall/Filtering.

Had an idea about setting up a rule system for various devices to be turned on/off automatically, but also manually.
Looking at
https://openwrt.org/_media/media/docs/howto/firewall_-_parental_control_settings_via_luci.png
the rules are per device, and to lookup the rules defined for a device one has to iterate all rules.
It would be more practical to have a GUI to enable and disable a set of rules for a device or device group (set of devices). And to do this manually or time based.
The GUI will consist of four sections:

A list of named rulesets to be applied (to be applied on a device, a set of devices, or all)
A list of named devicesets the rules should be applied on. A device can be in several sets.
A list of named timers settings: each timer setting contains a named schedule to turn-on/off
A matrix of rulesets on one side, and devicesets to the other [row and column headers]. The devicesets can be extended with all (present/known) devices and [all devices].

Now in each matrix cell there is:

A switch to enable, disable, or have a timer activation to perform a set of rules to a set of devices as indicated by the row and column headers
A selection box selecting the timer schedule.

My knowledge of iptables, etc is limited, just as how the above GUI should interact with them, how to generate/parse/extend using e.g. comment labels...
But I am curious about this idea/suggestion.

Please ask in the forum if someone is willing to implement such things.


[Meta-issue] Improve plotting API for consistency

This is a meta-issue to co-ordinate our efforts to on improving shap's plotting API.
Summary
The SHAP plotting API itself is currently inconsistent in a few ways, for example in return values, and in styles.
In a similar vein, the shap code itself is inconsistent in the use of matplotlib. We should standardise on using the explicit matplotlib interface (see below).
Related
I added the visualisation label to help track relates issues.
Consistency of the object-oriented interface:

#3070
#3206
#3351
#3391

Relating to style and customisation:

#1430
#1672
#2335
#2807
#3213
#3266

Context: Implicit vs Explicit matplotlib interface
Adapted from the matplotlib docs:
Matplotlib has two major interfaces, or styles of using the library:

An explicit "Axes"  or "object-oriented" interface that uses methods on a Figure or Axes object to create other Artists, and build a visualization step by step.

f, ax = plt.subplots()
ax.plot(x, y)

An implicit "pyplot" interface that keeps track of the last Figure and Axes created, and adds Artists to the object it thinks the user wants.

plt.plot(x, y)

The docs recommend the explicit interface, so we should prefer that.

Why be explicit
Lifecycle of a plot

Context: axes vs figure
We plan to move to an axes-based API, rather than a figure-based API.
From @thatlittleboy 's comment on https://github.com/shap/shap/issues/3213#issuecomment-1694171381 :

As we plan to move to an axes-based API in 0.44 (e.g. exposing the ax= argument uniformly to all of our plot functions), we should be manipulating the axes object rather than making changes to the Figure in general.
When we do so, my inclination is that when ax=None (not supplied by user), we will generate the Figure + Axes internally, in which case we can control the layout during instantiation, e.g. plt.figure(layout="constrained") or "tight", depending on our conclusions here. If the user chooses to pass in an ax, then all bets are off and they should control the figure layout themselves.

The ax argument might be exposed and returned like so:
def plot_thing(x, ax=None):
    if ax is None:
        ax = plt.gca()
    ax.plot(x, ...)
    return(ax)

For Jupyter notebooks, this approach works great! I'm using SHAP in a web application. Here's some sample code I wrote:
feature_importance = np.mean(np.abs(shap_values.values), axis=0)
feature_names = shap_values.feature_names
feature_names, feature_importance = zip(*sorted(zip(feature_names, feature_importance), key=lambda x: x[1], reverse=True))

I then pass this information into my display layer to render as a real-time HTML chart (in my case, chart.js). Has there been any consideration of an approach where:

Some of the logic (e.g., feature importance) is refactored into Explanation objects (or maybe somewhere else; I'm not that familiar with the code)
Making the various plot functions just do display instead of some of the analysis computation?

This would make it much easier for applications that embed SHAP, and also simplify the logic in the plot functions. But maybe I'm missing something. Happy to chat live if it would be helpful, and also willing to help contribute in this area.

From the prototype implementation of this new approach on #3523, I noticed a possible pitfall to avoid. Often the plotting functions are called like this:
def foo():
    f = plt.figure()
    shap.plots.bar(..., show=False)
    return f

To avoid breaking this pattern, we should avoid calling plt.figure() during the plotting functions, even if ax=None. Instead, we should continue using plt.gcf(), which will effectively be the same as plt.figure() if no current figure exists. This will keep the new code consistent with the library's previous behaviour.

Hi, I'm new to contributing and I would love to help out with a few of these. I'm happy to pick up the beeswarm plot.

Hi, I have a question regarding more complex plots like the heatmap. I looked at the code and it felt like a lot of hacky things are going on to fit the heatmap, the horizontal barplot, the f(x) line plot and the colorbar into one "Axes".
What is the opinion on treating the heatmap as a figure level plot with axes for the sub-elements? The improved API style could be provided by giving the option to pass a figure object, and by adding explicit labels to the axes, it could be easier to modify downstream.

Hi, I'm new to contributing and I would love to help out with a few of these. I'm happy to pick up the beeswarm plot.

@chriscave fantastic, great you to have you as a contributor. Give us a shout if you'd like any pointers - for example, feel free to tag me in a draft PR.

What is the opinion on treating the heatmap as a figure level plot with axes for the sub-elements? The improved API style could be provided by giving the option to pass a figure object, and by adding explicit labels to the axes, it could be easier to modify downstream.

The current approach has the advantage that all plots are axes-level plots, so they can have a consistent API. I would prefer to keep the API consistent and keep the visual appearance of the plots the same whilst we modify them. However, I'd be open to that change in future if it makes the implementation significantly clearer.
It would be unusual to accept a fig as an input argument, as defining which plots should go on which inner axes may become rather complex. It is probably simpler to start by accepting the ax directly.

The current approach has the advantage that all plots are axes-level plots, so they can have a consistent API. I would prefer to keep the API consistent and keep the visual appearance of the plots the same whilst we modify them. However, I'd be open to that change in future if it makes the implementation significantly clearer.
It would be unusual to accept a fig as an input argument, as defining which plots should go on which inner axes may become rather complex. It is probably simpler to start by accepting the ax directly.

Thank you for the reply and input. I can see the value of having a consistent API.
I am working on a multi heatmap plot for a multiclass classification problem and would like to try a few things, making it possible to modify the plot a bit (e.g. removing the colorbar, adding a sample annotation) and I'm not entirely sure if that works with the ax level API. @connortann Do you mind, if I tag you in a future PR?

Sure, we're always happy to have new contributors!

I created a GH Project to try to track how we're doing updating the various plotting functions. I don't seem to be able to make this project public; hopefully @thatlittleboy you should have access though.


How to REPL with Objection.js?

Coming from a Rails background and I so far love objection.js but I miss the repl with Rails/ActiveRecord. Is there a way to use Objection in my app via a repl to do various CRUD activities. Thanks.

I use objection via the CLI as a regular part of my dev workflow via the hpal CLI and hpal-debug.  It's based on hapijs, but you could have a simple setup that allows you to use the REPL for model debugging purposes without using hapi for your actual web server.

@stoplion  This is how I've set up my repl:
import { connect, Model } from 'my-objection';
import config from 'custom-app-config';
import * as repl from 'repl';
const replHistory = require('repl.history');

(async () => {
  // my connect function takes 3 args. all config options for 1, a second bool for whether to use
  // snakeCaseMapper or not, and a third for the connection name it's connecting as.
  //
  // I didn't like the idea of running the migrations with the ability to use snakeCaseMapper,
  // as I wanted them to feel "closer to the database"... so this is how i've done it.
  const migrationConnection = await connect(config.database, false, 'migrations');
  const knex = await connect(config.database, true);

  Model.knex(knex);

  await migrationConnection.migrate.latest();
  await migrationConnection.destroy();

  const replServer = repl.start('gca => ');
  replHistory(replServer, '.repl-history');

  replServer.context.knex = knex;
})();

I have this script as a yarn repl command.  once in the repl, you can import the models you wish to use. If you're using node 10, it's nice to use --experimental-repl-await flag, which allows you to do this at the root level of the repl:
await MyModel.query() to fiddle with stuff conveniently.
I think it's node 11, or 12, which has proper support for repl await at root level without the flag.

the package my-objection is a separate package I've made which contains all of my models, connection helpers, etc.
custom-app-config is another private package which helps with loading environment configuration.
Unfortunately I can't share those, but since you're already using objection, the pattern shouldn't be any different from what you're doing elsewhere.


"No release found" when first time installation fails

When first time installation fails even though most of the objects have been successfully installed, any upcoming upgrade will fail claiming that there is no release found.
This becomes really annoying and needs manual purging of the release for things to start working again.

I think this is a duplicate of #3353

ah @bmperrea you might be right. I assumed from the OP that "no release found" was more indicative of misconfigured RBAC but I can see how "has no deployed releases" can translate to the user as "no release found".
@Ahmadposten can you elaborate more on the problem as @jascott1 requested, with chart examples or terminal logs/steps to reproduce?


release fixes

Codecov Report

Merging #316 (356425f) into main (76ad140) will decrease coverage by 0.32%.
The diff coverage is 79.71%.

@@            Coverage Diff             @@
##             main     #316      +/-   ##
==========================================
- Coverage   92.45%   92.12%   -0.33%
==========================================
  Files          24       25       +1
  Lines        2876     2908      +32
==========================================
+ Hits         2659     2679      +20
- Misses        217      229      +12

Impacted Files
Coverage Δ

R/A_nhdplusTools.R
98.55% <ø> (ø)

R/get_geometry.R
100.00% <ø> (ø)

R/get_oaproc.R
92.96% <ø> (ø)

R/rebuild_topology.R
97.61% <ø> (-0.96%)
:arrow_down:

R/get_nhdplus.R
90.24% <75.00%> (-4.36%)
:arrow_down:

R/hl_graph_utils.R
76.74% <76.74%> (ø)

R/prep_nhdplus.R
94.94% <77.77%> (-1.16%)
:arrow_down:

R/discover_nhdplus.R
86.66% <100.00%> (ø)

R/get_nldi.R
88.88% <100.00%> (ø)

R/get_paths.R
96.65% <100.00%> (+0.76%)
:arrow_up:

... and 2 more

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


Restrict swipe/drag to horizontal events only

I've just finish creating a slider that can drag/swipe the slider left and right. My issue is testing on a mobile device. I've noticed that I can't swipe up and down and it stays stuck on the slider. How can I restrict the slider to only listen to horizontal events so that users can scroll up and down.
Scrolling or swipping up/down when I'm touching the slider tends to work on iOS(chrome) but on Android(chrome) I can't seem to scroll/swipe past the slider. It stays on the slider. I've created a fiddle below in order to check the issue
https://jsfiddle.net/clestcruz/xmup6naz/

I think this would help you:
https://github.com/hammerjs/hammer.js/issues/1014


Can i refactor some code ?

Can i refacto some code ?
example1 fombuilders to use YAGNI
example2 Controllers to use YAGNI too (NB: but the controller code will be much smaller and will not follow POLA standard)

Of course it is possible to help out. However, please only work on the main branch on version 3. Intervention Image version 2 will not be further developed by me.


Command to open chatbox in a new window

About the PR

Adds a pair of commands which open a chatbox in an in-game window. Fixes #20146 - now, you can open as many chat windows as you need, with different filters in each one.
Why / Balance

Admin tooling.
Technical details

Turns out we had all the technology needed for this, this PR is mostly just some glue code to initialize a chat window.
Media

Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog

:cl:
ADMIN:

add: "chatwindow" command has been added to open an additional chat window
add: "achatwindow" command has been added to open an additional chat window, preconfigured for monitoring admin channels

Will the second chat be available for regular players? The second chat helped separate the radio and regular messages, which made life much easier.


fix: overrides are always precise if they are functions #455

closes #455

Codecov Report

Merging #468 (2dac063) into master (33fb288) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #468   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files          194       194
  Lines         3486      3497   +11
  Branches       748       752    +4
=========================================
+ Hits          3486      3497   +11

Impacted Files
Coverage Δ

.../src/lib/mock-builder/promise/try-mock-provider.ts
100.00% <100.00%> (ø)

...s/ng-mocks/src/lib/mock-helper/mock-helper.stub.ts
100.00% <100.00%> (ø)

...g-mocks/src/lib/mock-service/helper.use-factory.ts
100.00% <100.00%> (ø)

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 33fb288...2dac063. Read the comment docs.


Missing dll, APPCRT140.dll

I have this issue, i installed 2015 redistributable, but this still pops up.
Any ideas how to fix it?

Some people have reported they needed to install both x86 and x64 redistributables to get it to work correctly.

@MartiUK Thanks, that worked!


band storage type matrix support

band storage type matrix and function ''_gbrts, _gbrtf, .....' being supported in a future release?

Hi, Sorry I have no plans at the moment. If you want to put in a PR I will help getting it released.


ACVNet-Fast

Hi, thanks for your excellent work and opensource code!
Are you planning to release the code of ACVNet-fast version ?
Hope for your reply.

Yeah, I will release the code in the future.

Any updates?


feat: add rbac to manager config interface

Signed-off-by: Gaius<EMAIL_ADDRESS>
Description

Add RBAC to manager config interface.

Related Issue

Motivation and Context

Screenshots (if appropriate)
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation Update (if none of the other choices apply)

Checklist

[x] Code compiles correctly.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Codecov Report

Merging #1179 (0aa64b7) into main (f2031d5) will increase coverage by 0.16%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1179      +/-   ##
==========================================
+ Coverage   46.31%   46.47%   +0.16%
==========================================
  Files         132      133       +1
  Lines       10250    10496     +246
==========================================
+ Hits         4747     4878     +131
- Misses       4960     5063     +103
- Partials      543      555      +12

Flag
Coverage Δ

Object-compatibility-e2etests
?

e2etests
?

unittests
46.47% <ø> (+0.16%)
:arrow_up:

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

Impacted Files
Coverage Δ

client/daemon/rpcserver/subscriber.go
49.56% <0.00%> (-9.81%)
:arrow_down:

client/config/deprecated.go
0.00% <0.00%> (ø)

...ent/daemon/peer/peertask_piecetask_synchronizer.go
46.91% <0.00%> (ø)

client/daemon/peer/peertask_conductor.go
58.23% <0.00%> (+0.86%)
:arrow_up:

client/daemon/daemon.go
6.54% <0.00%> (+1.41%)
:arrow_up:

client/daemon/peer/peertask_piecetask_poller.go
53.33% <0.00%> (+2.98%)
:arrow_up:

client/daemon/peer/peertask_bitmap.go
72.22% <0.00%> (+3.47%)
:arrow_up:

client/daemon/peer/piece_broker.go
88.88% <0.00%> (+3.70%)
:arrow_up:

client/config/dfget.go
26.74% <0.00%> (+5.69%)
:arrow_up:


fstab mount point with spaces in prefix.

Tried to add line to fstab with spaces in prefix:
goofys#"example:PREFIX WITH SPACE" /mnt/example fuse     _netdev,allow_other,--file-mode=0666,--uid=1002,--gid=1002,--dir-mode=0775,--stat-cache-ttl=1s,--type-cache-ttl=0s,--profile=example    0       0
Also tried goofys#example:"PREFIX WITH SPACE" .
Getting error mount: /etc/fstab: parse error at line 20 -- ignored .
Is there way to do that?