Visual script does not simplify the programming process

I can not learn to use Godot. I have a bit of programming experience, but probably not enough. I'm just not a code person. And I want to create games.
I know there is a visual script. But it is just the same code only in a messy way. There is no visualization of things. No icons. And much worse, programming is the same programming. There is no simplification.
 In Gdevelop I was not bad at all. It just lacks so many features, and there are built-in bugs, that I keep trying Godot.
Visual programming is supposed to bring things closer to a human language. Make it understandable.
And I have pretty good proof of my claim, from this Gamesfromscratch video:
https://www.youtube.com/watch?v=-vo7jTQE7dc
In the passage he talks about Godot, he says there is no good reason to use Visual Script.
I'd really love it to change.
I like Godot.

Talking about GDevelop, would be really nice to have this in Godot: #17795
I was creating games using similar software (The Games Factory) back in elementary school with absolutely 0 programming knowledge. There's probably nothing more simple than event sheets, when it comes to making games. And if they were in Godot, ability to mix them with standard scripting would create a very powerful tool.

Talking about GDevelop, would be really nice to have this in Godot: #17795

I know that. The solution he offers there is more interfaces and less conceptual. He simply arranges things differently. It is still very misunderstood and abstract. This is very far from the way things work in Constract and Gdevelop.
And I really do not care if the interface stays the same (drag and drop). I think that the main problem is conceptual.
Also in this video:
https://www.youtube.com/watch?v=9xGU0Cqv-J4
In the fifth minute he mentions Godot and says he does not put it on the list because it requires a background of programming.

How do you suggest improving visual script conceptually?

Icons. Per function. And they should pass the message wisely.
Transferring the mindset to a more humane nature. A person who is not a designer is not really sure what the 'return' thing is. For example. The user simply has to tell the computer that if an X happens, it will work in Y and in human terms. If the player is in the friction with the bomb, the image of the bomb changes to the animation of an explosion, the object of the bomb is deleted, and the player's 'life' variable drops 20 points.
Maybe we can make any automations, by default, things that most people do not understand. That not everything will have to be said by the developer.
Even if the move reduces the developer's options in relation to GDscript, as long as it presents an advantage in other areas it is worthy.
The situation today is that all online tutorials for Visual Script are finished in comparison to GDScript, which shows how much more short and easy this code is.
If the visual script will go toward easier to use, even if it will reduce some of the options that a programmer has with code, it will eventually expand the target audience of Godot. And I think this is the goal of a visual script. Give more tools that fit more people.

Perhaps some of this can be achieved by better "helper" blocks in visual scripting that wrap common node types and perform their operations on them in a more visual way.  The way common functionality is exposed to visual scripting seems definitely more suited for a use case like "developer needs to make a sanitized interface for someone on the design team to use", but even then, it looks like it exposes a lot of stuff you may not want them to see.
Alternatively, visual scripting might benefit from existing nodes being "marked up" the way things are given attributes in the docs -- something that could behave like the aforementioned wrapper helpers, but with a bit less functionality (ie:  they couldn't do custom UI visual nodes); adding icons, grouping by functionality instead of alphabetically, re-arranging/renaming functions on a member-by-member basis, and only exposing the most common functionality unless it needs to be "dug into" (something like giving each member a "priority level" for UI visibility that hid the functionality behind "accordion groups", for example).
It would take a lot of effort to find all the places visual scripting can be best helpful to non-programmers in terms of how to present all nodes' functionality.  As it currently exists, it feels even more cumbersome to work with than gdscript for just about everything, even for testing simple functionality.

One of the enhancements we're looking at is VS Custom Nodes savable as resources:
https://godotengine.org/article/gsoc-2019-progress-report-1-part-1#visual-scripting

Work of the Super Node or Visual Script-based custom nodes/modules feature for greater reusability and modularity of the Visual Scripting system.

The idea is the community and developers can create a library of custom nodes. @swarnimarun
The tools programmer in the team would create these nodes and less technical developers would use them.

Aww, GDevelop has event sheets which is probably what works for the OP. In Godot's VS, you are editing a diagram, connecting / linking / unlinking nodes, etc. Probably way different of learning something.

Aww, GDevelop has event sheets which is probably what works for the OP. In Godot's VS, you are editing a diagram, connecting / linking / unlinking nodes, etc. Probably a way different experience between the two?
Conventionally, artists created their art and handed it off to the programmer, then the programmer coded their game. Godot is a game engine, and in my opinion not really an art tool. So if something is not working the best way for a designer, is kind of beyond the scope of what the engine should offer. However, if Godot had a lot of art creation abilities, I could see this being a bigger issue.
I think listing improvements that could be made to Visual Scripting is good, but I would not expect event sheets or an overhaul, just my 2 cents

You didn't get me right. I'm not trying to get Godot to switch to a similar interface to Gdevelop. I don't think that's the point. For example, GameMaker Studio 2 uses the same drag-and-drop system as Godot but is agreed by everyone as much more recommended for beginners. Maybe he is a better example of inspiration. I don't really know what's going on there. I've only tried Gdevelop. But there is something about Godot in these programs. They are more suitable for non-programmers.
And I can't understand any other purpose for the visual script than giving people who aren't programmers to create the games they want.
Nowadays people just don't use Visual script. No one finds any advantage there.

I wanted to chime in on this, I noticed when using the visualshader graph that for example, rotating a texture required manually multiplying the coordinates with a rotation matrix. That type of stuff is way out there for newbies, and kinda annoying for experienced shader writers too(multiplying matrices isn't hard, but is super fiddly).
Looking at the visual script, I, as an experienced programmer, noticed the following:

There's a ton of programmer lingo. Either this...
a. gets rewritten to be more human friendly.
b. gets tooltips with explanations. Like, if I have 'max', and look up the docs for it, I find a perfectly fine explanation. If that could get stuffed into a tool tip when hovering over the block or over its entry in the functions list, that might go a long way in reducing the opaqueness. This should also go for the categories like 'flow control'.
There's a lot of setup work required for fairly simple things. So for example conditional statements. In script these are three lines, in visual script they're split into the condition and the branches. Maybe here it would help if there was a wizard to help people find the node they're looking for. So like one that helps them find the input, or one that helps them formulate that they want to check if three values are all true at once and then outputs the appropriate branching statement. The way how you can are asked for the function of a given node when it is dnd'd into the window is a good example of this.
The fact that nodes need to be dnd'd into the visual script window to access them should be encouraged in the UI. Like, a small label somewhere.
Similarly, in 'matches' dialog, the unique functions to a given base type should probably be listed first. Right now this ordering starts with the non-unique functions, which is annoying to experienced users, and new users will not be able to see that the available functions are different per node, because the entries look the same at first glance. The node docker already does this, and it is really nice there.

The one thing the visual script editor does do really nice is that when you drag from the output it'll give you a window with a list of possible nodes and explanations, as well as the similar coloring of compatible types. It needs more of that.
Overal, I guess that part of the problem is that VS right now is exactly as dynamic as GDscript, and that means it feels like you're putting together a racing car while all you really needed was a soapbox on wheels, so you'd get overwhelmed by the minutia of how exactly the wheels should attach to the axle, trying to figure out what the simplest method is supposed to look like :D

I think the main issue is having a larger range of built-in behavior. Something like GDevelop, which seems more tailored to people with less programming experience, has this.... but also something like Unreal Engine tailored for larger scale projects have built-in behavior. No matter how you do it, programming is still programming. It doesn't matter if you're using icons or words.
Visual Script is too vanilla. It's just icon drag and drop version of code. It can remain the way it is to maintain versatility, but to help beginners it needs a larger range of built-in behaviors.
Visual Script to me feels like Blueprints in Unreal Engine. It still feels like you're writing code, but instead of typing words you're dragging icons and connecting stuff.

Visual Script to me feels like Blueprints in Unreal Engine. It still feels like you're writing code, but instead of typing words you're dragging icons and connecting stuff.

I'm not really familiar with the blueprints system, but from what I've seen on the Internet, it's much more recommended than visual script.  For example, in the first video I attached above.

I don't see why it would be more recommended over Visual Script, they're practically identical. The thing is, unreal doesnt have a scripting language. Blueprints is basically it. You could however compare its usefulness against Gdscript.

@sparkart
Maybe.
But even so. visual script can make things much more accessible. At Gdevelop I learned to work without any tutorials. At Godot I read and watched so many tutorials and still could not make progress.

That's the beauty of out of the box functionality. What you're missing from Gdevelop that isnt in Godot is built in behavior. I think that is the key ingredient that you're missing. I don't think Visual Script is useless, but I agree your concerns are valid. I think the question to ask is how can we make this process simpler? For example, if you want to make a platformer game... why dont Godot just ship with a platformer template. You would still run into the issue of needing to interact with the scripting language to adjust things to suit your needs (an open source c++ game would be useless to a beginner trying to adjust it to their needs).
To address your concerns, Godot needs to solve the issue of not shipping with alot of built in behavior that its bloated, but to streamline the ability to add complex behavior without needing to do any programming at all. And when I say programming, I mean anything related to putting together logic, whether its visual nodes, drag and drop, code, event sheets, etc.. the easiest game engine shoukd allow you to create a game by basically providing your own data (assets and variable values). I think that should be the end focus of Godot, low level functionality but also high level that you can make something in 5 minutes.

From my very old experience with The Games Factory (ancient software from Clickteam), it had for example two approaches for making a platformer:

The easy way: using built-in platformer controller. It was horrible, character could get stuck on ceiling, jumping worked like 32-directional movement and if you wanted to e.g. shoot forward, you had to use some hacks to remedy the direction issues.

The hard way: implementing the controller yourself, using a set of invisible marker objects and basically "programming" the behavior. Some games did this and it worked really well, but the 10-years-old me didn't understand how this works.

The point is, if you wanted to make any serious game, you had to do it the hard way. The default crappy behavior was only good for useless prototypes or gamedev children playgrounds. If Godot had built-in stuff like this, it would have to be really solid. But even then, 90% of people would create their own behavior anyways and the default one would be used only for prototyping.
It's pretty impossible to make a serious (or at least, unique) game without programming and going beyond what non-programming tools provide for you. And since we can't appease all people and their use cases, it would be the best if there was just a possibility to re-use VisualScript nodes. This way people could share their "platformer controllers" and what-not.

@KoBeWi
What is the difference between the behaviors that Godot will default to the behaviors that users share?  If so, behaviors that come with the software can be much higher in quality control and prevent the bugs you mentioned above.  I'd really like to be a master of programming to create crazy things.  but I do not.  And I love game design.  So I want to believe that software like Constract 3 and Game maker studio 2 can create good games.  And I want to have such an open source option.

What is the difference between the behaviors that Godot will default to the behaviors that users share?

If Godot has 100 built-in behaviors, it will bloat™ the engine. I wouldn't underestimate community here. If it's not created officially by developers, it doesn't mean it's bad (and the other way around too; the bugs I mentioned were in commercial software).
Of course this could also fit for the plans with the "official plugin" repository, so we could have these behaviors being high quality, but keep them optional and easily accessible.

@redus what you think?

I mean, @reduz what you think?

@KoBeWi I messed around with The Games Factory back then too, and the 15-16 year old me couldn't make sense of the complex stuff either, but the event sheets were indeed great. Such that I still managed to make a half-assed pacman that actually kinda worked, among other things. :)
I wonder if that's not a kinda-of-forgotten relic of a system that could be being explored more often.

Hello,
I have the same problem as @brigazvi
My background is in computer graphics and I consider myself a very visual person. I have tried Godot’s visual scripting system many times, but like the previous posters already discussed, it does not actually simplify things as it is meant, but is basically coding 1:1 only you drag blocks around (more convoluted than actual code).
Otherwise I love the Godot way of doing things, the scene nesting and nodal workflow is just pure genius(better than Unreal or Unity). What I also consider a BIG benefit is the program size - compared to for example Unreal or Lumberyard that take insane amounts of disk space and resources. The one thing that is missing for me is the beginner friendly scripting system.
For a long time I have been searching for game engines that I can get into without much coding knowledge. For 2D engines so far I found Conctruct and Gdevelop for being the easiest to understand and get things going fast. For 3D stuff there is not much going around in terms of ease of use. A surprising engine is\was in Blender. The Blender game engine logic bricks are what I am looking for.
I have two suggestions for this problem.
First is to implement something similar to the logic bricks in the Blender game engine. I discovered this only recently. Reason being that paradoxically one of the hardest to use 3D packages that has/had one of the easiest to understand scripting systems. I have looked at a lot of 3D game engines but this is by far the easiest system to understand and really fast to get stuff going. The logic is very similar to Construct and Gdevelop event system. For example (Press W -> and -> add +1 to object coordinate X). With something simple like this you can get a 3D object moving in 3D space.
Explanation video from Gamesfromscratsch channel.
https://www.youtube.com/watch?v=cBhEgQVpv2M
The second suggestion is to make something similar to what a 3D program called Cinema 4D uses to make custom scripts for custom interactive stuff. It’s called Xpresso. First reason I bring it up is because I use Cinema 4D daily(a biased opinion) but the second reason is that Cinema 4D is considered one of the easiest to use 3D programs out there. At first glance Xpresso looks a little daunting and visually is very similar to what Godot already uses but if looked a little closer it’s core system is much simpler. A more understandable visual scripting system for beginners I would say.
Explanation video 1
https://www.youtube.com/watch?v=k-1xzR2XS9Q
Explanation video 2
https://www.youtube.com/watch?v=3vCnuIDGhyM
The truth is probably somewhere in between. But if something similar would be developed or the current Godot visual scripting would be developed similar to the previously mentioned systems then Godot would gain many die hard users. Especially people who are very visual or not so code friendly.
Ragnar

Working on a Blocky or Construct like system is a different than the current visual script.

https://developers.google.com/blockly

https://www.commonsense.org/education/website/construct-2
What I want to do is debug and make the current Visual Script based on flow graphs better and not create a completely different system.

https://en.wikipedia.org/wiki/Flow-based_programming
A GSOC 2020 project is to add expand and group nodes into grouped nodes with input and output port.
There's also a work proposal for Visual Script formatting. Like make a series of nodes pretty and well laid out.
There are also workflow issues with using visual script. It's very difficult to convert gdscript to visual script.

There are also workflow issues with using visual script. It's very difficult to convert gdscript to visual script.

Related feature request godotengine/godot-proposals#1240 (nevermind misleading title).
Also see reduz opinion on this on Twitter:

Unlike Unreal, this is more meant as a complement to programmers, so game designers, level designers, etc. can work more easily.

I would just like to add that the UI / UX of the Blender node system is superb. Very intuitive, clean and well thought. I've tried Blueprints, Bolt and obviously, Godot VS, which all felt lacking in different ways.
Quickly pointing out things that could be improved in Godot VS that work well in Blender:

Zoom in / out with mouse wheel (I know this issue has already been addressed, but it's still a major miss for now);

Minimize nodes (helps to save space for nodes we all know what they do);

Show collapsed hierarchy in node search tree.

Hide the var type label for the input / output of each node. Isn't the color enough? I think the labels just add to the mess.

Cut & Copy / Paste of nodes is not working.

When we move frames of nodes, the inner nodes should move as well.

Easily create loops and groups inside a script and call them.

Allow nodes and groups coloring for a good organization.

What do you think?

zoom in and out is still broken
minimize nodes don't do as much as grouping nodes
The two hiding / minimizing features make it more confusing I think. Also colour blindness
I agree that comments should move the nodes inside
Cut and paste yes!
Google Summer of Code 2020 is on Grouping and Ungrouping nodes https://github.com/swarnimarun/godot/pull/7

The two hiding / minimizing features make it more confusing I think. Also colour blindness

Oh yes, I forgot about color blindness. But IMO there could be an option to toggle the vars visibility. It's really a waste of space when you can read from the inputs / outputs colors.
I'll build Godot from source and explore the code to see if I can be helpful in any way.

I love the way how bolt/unity can scan new components and code to offer total generic new units. And also to have two kind of flow-diagrams: a flow graph and a state graph aka visual state machine. This helps a lot.
Blueprint/unreal is awesome in the way how to group nodes/units as a collapse-to-function, -to-macro, -to-node. And also the deeper penetration in the areas of HUD, menu, physical based materials (water / fog), level / scene states etc. pp. makes blueprint awesome.
So it is not the point to decide coding or piping. It should be both. Visual Scripting is a genius way of reuse code. With a good, colorfull grouping function is the ready, understanding of logic much, much easier, also because you have a second dimension. Code is only from top to down. Visual Pipelines from top to down and(!) left to right.
Because I'm in love with Godot, I really, really would wish to learn from the other visual scripting Ideas and create the best of all.
Here my 5 most wishes:

Grouping/Collapsing (like blueprint)
Reflection-Based (like bolt)
Tooltips, Tooltips, Tooltips
Inline Tutorials (like unreal)
Cross-Reference to read, learn, discover all (no one has)

I just start using Godot. IMHO, Visual Script really helps. In fact, it's my primary way of coding because I can understand the code in a visual way. I can understand GDScript and even some of C# when I watch the tutorials but unfortunately, I can't replicate that understanding in my project. With Visual Script, it's like I put together many jigsaws into a picture. I can guess the piece I needed for the final image in my mind. Therefore I think Visual Script really does help the programming process a lot (at least for me who's just starting).
My wishes list regarding Visual Script would be:

Real-time debugging like Bolt. >>> It really helps for someone who doesn't have a solid understanding of coding. There was a lot of time when I totally lost it, for example, the time when I used condition if and switch, although they're very similar, their logic is very different because you can't turn on 2 switches at the same time.

Infinity zoom out. >>> Most of the time, you will have very long horizontal nodes. It's inconvenient and time-consuming to pan all the way from the first to the last.

Search for the comment or title. >>> Currently, it's very hard to search for nodes. The comment is not very well implemented as you can't find them using keywords. I think this feature is very important as most of the time not all nodes are presenting in the view. The ability to have a custom title of any node would be a great feature to implement in the future though.

Focus on wires/connections of the selected node. >>> When you have a lot of wires connected, it will be very hard to track down the logics that are connecting to any node. I think this would help.

More tutorials. >>> Currently, most Godot tutorials are in GDScript, even in the official Godot Docs. I have to find a way to translate it to Visual Script so I can fully understand it (which is very hard for me).

Performance >>> This wish might be out of the world, comes out of someone who doesn't know how to code anything properly. From my understanding, the Visual Script nodes are basically logic nodes. Therefore is it possible to make the engine automatically convert the node logic to C++ underlying upon export to gain the performance benefit of C++/GDNative?

Performance >>> This wish might be out of the world, comes out of someone who doesn't know how to code anything properly. From my understanding, the Visual Script nodes are basically logic nodes. Therefore is it possible to make the engine automatically convert the node logic to C++ underlying upon export to gain the performance benefit of C++/GDNative?

Could be in theory converted to GDScript with typed instructions somehow. In either case, not really trivial to do, see also https://github.com/godotengine/godot-proposals/issues/1240#issuecomment-662571669.

I just start using Godot. IMHO, Visual Script really helps. In fact, it's my primary way of coding because I can understand the code in a visual way. I can understand GDScript and even some of C# when I watch the tutorials but unfortunately, I can't replicate that understanding in my project. With Visual Script, it's like I put together many jigsaws into a picture. I can guess the piece I needed for the final image in my mind. Therefore I think Visual Script really does help the programming process a lot (at least for me who's just starting).

I'd like to share @reduz design vision behind Visual Script further, I've stumbled upon an article: https://godotengine.org/article/godot-getting-more-languages, see "Why Visual Scripting?" (to those who read godotengine/godot-proposals#575, it's exactly the thing I'm talking about the "why" part behind Godot's development, which is only written on the level of articles, and not official documentation...). Emphasis mine:

Another language currently being added to Godot is VisualScript, our take on visual programming. We are using an approach similar on the surface to Unreal's Blueprint, but pretty different under the hood.
As we have seen so far many Godot users and other developers puzzled about Godot adding this functionality, we want to make very clear that it is not our intention to replace GDScript or traditional programming for a visual approach.
To make it clearer, it is not our belief that forcing programmers to write code with visual blocks will result in a more efficient workflow. We know other game engines and solutions try to sell you this point of view, but rest assured that this is not our view or intention. We stand by programming and still believe it's the best.

I'm saying that perhaps the community sees this differently, but then there's unintentional "deceiving" going on. That article is 4 years old, though, so perhaps the vision has changed.
Perhaps if we really go the beginner-friendly route, maybe we just need another language designed exactly for that. But I think it won't be implemented in Godot, though. Quoting groud in https://github.com/godotengine/godot/issues/17795#issuecomment-376498871:

A good idea for a plugin. But officially maintaining two visual scripting systems would be a pain, and for little gain.

The good news is that it's totally possible to create a brand new language via C++ modules in Godot, similar (or even better) to Unreal Blueprints. 😃

I'm not a Godot user, but I want to be. However, I ended up here after searching online for information about Visual Scripting, and I too think it's too close to actual scripting and it has unfortunately scared me away, as I'm not a programmer.
Due to work, I had to learn the Unreal Engine, and they seem to automate some of the programming aspects better. They have some interesting flow control nodes that have built-in behavior ("do once", "do n", "flip flop", "gate" that can be locked an unlocked, etc) and some nice visual things like enums become nice little drop down lists to select from making nodes close to natural language readable.
But the biggest feature of them all (for me) is the timeline node. In one extremely powerful node, you can do simple animation and fire off events without having to think about frames or synching or anything, and it's all truly visual. It's so incredibly powerful and I use it all the time and I wouldn't want a world without it anymore.
Then recently, there's a whole world of specialty nodes for skeletal animation to interact with IK and physics that they added, but that's way above my head for now. I've heard it enables technical artists to do things that they had to ask programmers for in the past.
So, I'll check back in a few years and see if there has been any progress. I'm hoping by then that visual scripting in Godot will look less like scripting and more visual. :)

Godot's equivalent of the timeline node is the Animation and AnimationPlayer, and those are amazingly powerful too.

How do you suggest improving visual script conceptually?

I think maybe it should be more similar to Unreal's node system.

I hope people are still working on this but at the status of this post, I don't think anybody is. The visual scripting part of godot has no benefits and it's very messy and difficult to get into. I've tried using it multiple times but it's because I tried that I put a lot more effort into learning GDScript instead just to escape the mess which is visual scripting in Godot. There are many great examples of other engines and programming languages with visual scripting being a decent tool and sometimes even more convenient than scripting things yourself.
if my programming skills would have been better I would have tried to give this a try myself, so I hope somebody will finally give visual scripting in Godot some love.

I hope people are still working on this but at the status of this post, I don't think anybody is.

One of the GSoC 2022 ideas is about improving visual scripting: https://github.com/godotengine/godot-proposals/issues/4064

Tangent (but I'm not sure it's worth opening a separate proposal for) - usability of visual shaders and visual scripting both suffers from the fact you can't open them "full-screen" (or at least like the script editor does, using all the space that's not taken up by tree and inspector)

i cannot agree with the comments here, the visual shaders are excellent, people have not "got them" or they expect them to make programming easier, which i'm not sure a visual system will ever truely do anyway
the problem for me is only a lack of docs... there's not even a reference doc for example on what the individual nodes do
i recently have built a visual shader copying a spatial, but i have added vertex code because i wanted ocean waves..... this is far better organised that converting a spatial to script and then adding my jury rigged code to it
the process is badly organised of course... however with a visual shader i can solve this organisational problem.... so i thought i'd just share there's a genuine argument of something i can't do with written shaders.... organise things in a modular fashion without copying and pasting the same code blocks everywhere

This issue is more about VisualScript, not VisualShader. Visual shaders are great and people generally don't have problem with them.


Error initalizing labels

Here are the logs:
Processing #7
Initializing labels...
##[debug]User prefers to use the "blocked" label
Error: Cannot read properties of undefined (reading 'name')
##[debug]Node Action run completed with exit code 1
##[debug]Finishing: Run Levi-Lesches/blocking-issues@v2

Here are the relevant lines:
https://github.com/Levi-Lesches/blocking-issues/blob/dd338e8bfd795a32affc048e2175bb675127cc39/src/model.js#L15-L32
Given the lack of another log, it seems the error happens on 20 or 21. utils.defaultLabel should not be undefined since it's a constant. I'm unsure why existingLabel would be undefined since it's coming straight from github.getLabels().
In the future, add a debug log for labels so we can always inspect which labels to choose from.

Fixed in v2.0.1, it was a matter of checking for === null when the value was really undefined. Switching to == null fixed this.


Known issue: occassional keyboard incompatibility

Latest report from BoltMitch
While using Logitech K760 wireless keyboard
While holding the run button I can only jump while running left, not right.

Seems to be a GBStudio issue, not P+


hspec-megaparsec 0.3.0

hspec-megaparsec-0.3.0 (Mark Karpov<EMAIL_ADDRESS>@mrkkrp) is out of bounds for:

[x] cassava-megaparsec-0.1.0 (==0.2.*). Stack Builders<EMAIL_ADDRESS>@stackbuilders. @jpvillaisaza @jsantos17 @jsl @mrkkrp @sestrella
[x] stache-0.1.6 (==0.2.*). Stack Builders<EMAIL_ADDRESS>@stackbuilders. @jpvillaisaza @jsantos17 @jsl @mrkkrp @sestrella

Should be resolved now, I updated info for the packages on Hackage to allow hspec-megaparsec-0.3.0 which has no breaking changes.

Any update on this?

Thanks for the PR, you're right, this seems to be resolved.


DDT-758 - Add fields to booking

@FinnAtAsseco Could you add these changes to your PR? https://github.com/dcsaorg/DCSA-Event-Core/pull/180


One windows check

[ ] I have added an entry to docs/changelog.md

Summary of changes
This just centralizes the code to check if we are running on Windows to constants.py.
Previously, there were a couple of different places where the code checked if we were on Windows.  A bunch of modules were even importing from utils.py, which in turn was importing from constants.py!!
Test plan

Tested by running
# command(s) to exercise these changes

@uranusjr looks like you had the same idea in #606 😄

@uranusjr looks like you had the same idea in #606 😄


Documentation of hyper parameters

Right now we only have an overview of hyper parameters where the reference implementation of the authors differ from paper. I wonder if we should put a table of every hyper parameter together with their values on top of the API reference. This way we could give a far better overview
If we go for this it might be viable to implement a HyperParameters class for each paper where we can pull all default values for all the functions and classes.
Cc @jbueltemeier

That's a good idea. It would also be good to document other paper relevant attitudes in this list? For example, the optimizer used, the dataset on which the training is/was performed, etc


Spurious reasoning for C# over Python

It's true that Python is an interpreted language, which makes it slower compared to compiled languages like C#. However, in the context of machine learning (ML) and scientific computing, Python's performance is not usually the bottleneck. The heavy computations in ML are offloaded to highly-optimized C/C++ libraries (like NumPy or PyTorch's underlying libraries) or to GPU-accelerated libraries like CUDA. This means that, in practice, ML code written in Python can run just as quickly as similar code written in other languages.
While Python has a Global Interpreter Lock (GIL) that can limit the effectiveness of multithreading by allowing only one native thread to execute at a time. However, this does not mean that Python "lacks true multithreading capabilities". Python's threading module does support multithreading, although it might not provide a speedup for CPU-bound tasks due to the GIL. However, for I/O-bound tasks (like loading data from disk), Python's multithreading can provide a significant speedup. Moreover, Python has other ways to achieve parallelism, like multiprocessing (via the multiprocessing module), and many of the underlying C/C++ libraries used in ML can effectively utilize multi-core processors independent of Python's GIL.
Developer Ecosystem: Python is currently the dominant language in the data science and machine learning field. Most of the major ML libraries (like TensorFlow, PyTorch, SciKit-Learn, etc.) have been developed in and for Python, and Python's simple syntax and vast ecosystem of scientific computing libraries make it very accessible to new developers. While developing ML tools in C# might indeed attract developers from the C# ecosystem, it does not necessarily "enable a wider range of developers to make use of Stable Diffusion". In fact, it could limit the reach of these tools, as they would not be usable by the large number of developers who are already working in the Python ecosystem.
Can you please update the text to be more accurate?

Hi, I appreciate the feedback, however I think you read that with a particularly negative minded light, so I'd ask if you can take a moment to understand the intended meaning clearly before we continue (and, when you feel you do understand how it's intended, provide suggestion(s) for how to phrase it more clearly so that the intention gets across).

multi-core functionality was needed here because this project does a lot more than just simple inference, it's a webserver, multi-backend-orchestrator, specialty processor, large-dataset manager, ... and it's designed with the intention to be accessible to several users simultaneously (not yet fully implemented) - if it was bound to a single core as would be the case in the python GIL system, many of these functionalities would be limited in capability as the server's usage scales up. The actual inference backends are currently still in python and launched as sub-processes (however I'd like in the future to have a native C# execution engine available as an option - that's delayed to focus on more important things though)

having tools in more languages is absolutely increasing the range of accessibility. I'm not taking away any python tools, I'm adding some non-python options.

okay. those are good points. i'm sorry if my comment came across as overly critical. I figured the details I provided would be enough on a technical level. I have taken some time to rewrite it based on your feedback, so that there is a suggested change which outlines the strengths of the C# approach while ensuring the Python is still outlined:

This project employs a C# backend server to enhance performance and manage complexity effectively. Our system's requirements include serving multiple users, orchestrating numerous backends, handling extensive datasets, and executing specialized processing tasks. To achieve optimal performance, we sought a language capable of fully leveraging multi-core capabilities to scale up efficiently.
Python, the current Gold Standard for machine learning projects, offers considerable flexibility and functionality. It is well equipped to handle multiprocessing tasks effectively, bypassing the limitations of the Global Interpreter Lock (GIL) that impacts multi-threading. However, for a system like ours that requires extensive concurrent CPU-bound tasks and superior multithreading capabilities, C# was a more fitting choice.
By adopting C# for our project, we're broadening the reach of Stable Diffusion tools beyond the Python ecosystem. This choice offers options to developers more comfortable in the C# environment without displacing Python tools. Essentially, we're enriching the existing toolkit with more diverse programming options.
It's worth noting that while C# offers significant advantages in certain areas, like any language, it's not without its challenges. For instance, managing memory in C# can be complex due to its garbage-collected nature, particularly when dealing with large datasets. However, we believe the advantages outweigh these complexities in our specific use case.
Our current architecture leverages the strengths of both languages: we use Python sub-processes for our inference backends, and C# for multithreaded processing and serving. Our future plan is to introduce a native C# execution engine as an alternative, maintaining Python's flexibility and functionality while reaping the performance benefits that C# provides.

Hi, I appreciate the feedback, however I think you read that with a particularly negative minded light, so I'd ask if you can take a moment to understand the intended meaning clearly before we continue (and, when you feel you do understand how it's intended, provide suggestion(s) for how to phrase it more clearly so that the intention gets across).

I would like to echo the sentiment from the OP that the ML space is entirely in python, and by developing in .NET, you are effectively isolating your tool from the ability of many would-be contributors from this space to contribute. That audience is the most likely to be engaged in actually contributing.

multi-core functionality was needed here because this project does a lot more than just simple inference, it's a webserver, multi-backend-orchestrator, specialty processor, large-dataset manager, ... and it's designed with the intention to be accessible to several users simultaneously (not yet fully implemented) - if it was bound to a single core as would be the case in the python GIL system, many of these functionalities would be limited in capability as the server's usage scales up. The actual inference backends are currently still in python and launched as sub-processes (however I'd like in the future to have a native C# execution engine available as an option - that's delayed to focus on more important things though)

I feel there may be a gap in your understanding about the performance limitations of python. The points talked about here sound academic, and are probably rooted in a time when a historical python version (such as 2.7) was the norm. As python is now, I find the idea that the performance characteristics of python necessarily being a limiting factor as outdated at best. Between plain old threading, coroutines, and multiprocessing - all features of the standard library - and smart architecture, I suspect any well enough engineered system could - in pure python - stand up to the rigor of the features needed to make the Swarm project work.

having tools in more languages is absolutely increasing the range of accessibility. I'm not taking away any python tools, I'm adding some non-python options.

And to reiterate, while you're not technically removing anything, you're obscuring the ability of anyone already in this space and not familiar with C# to contribute or consume it in a more meaningful way.

thank you for echoing my original sentiment, and expanding upon it. however, I agree with Alex. my initial reaction was knee-jerk based on the same incorrect assertions, but having an expanded ecosystem in the direction of C# is unlikely to harm the python ecosystem.
on the contrary, developers who encounter the limitations of C# development are likely to look toward solutions like huggingface/diffusers and make the jump into learning Python. but if they never hit those limits, and the available C# solution works for a C# developer, that is a net win for StabilityAI, and C# developers.

I didn't imply, nor do I believe, that choosing .NET is an inherently bad idea, nor do I think it will harm anything. I do, however, think the reasons given for it over python are spurious at best.

thank you for echoing my original sentiment, and expanding upon it. however, I agree with Alex. my initial reaction was knee-jerk based on the same incorrect assertions made in the README.md - but having an expanded ecosystem in the direction of C# is unlikely to harm the python ecosystem.
on the contrary, developers who encounter the limitations of C# development are likely to look toward solutions like huggingface/diffusers and make the jump into learning Python. but if they never hit those limits, and the available C# solution works for a C# developer, that is a net win for StabilityAI, and C# developers.

yes. i think "we just wanted to do this for the C# community, and it's what we are comfortable with" makes total sense too.

Sure. That's a business decision that I wouldn't argue with. They are not compelled to use any one technology, but as originally stated, its not accurate to say python is fundamentally less capable to do the stated goals.

The fact that python can use more cores by spinning up more processes is technically correct but not relevant, that is not a high-performance multicore solution, that's a hack. Python is simply not an ideal choice for projects that need high performance multicore processing.
The decision was not made flippantly. I did significant testing. Some of my experimental 1:1 code comparisons ran literally orders of magnitude faster in C# than they did in Python, even the singlethreaded ones. I chose the high-performance option because it was the high-performance option.
You can have your own opinions and preferences, if you want to use python for things that python is less capable at than other tools, that's your choice, but I chose to use the technology that does better at the goals we needed, and I tried my best explained that choice in the readme.
If you would like to help improve the phrasing of that explanation, that's welcome, but the aggressive response here is not needed.

ps I appreciate your responses here @bghira
I don't think that the suggested rewrite there would be best, just because - well, it's a 5 paragraph essay replacing what was meant to be a couple sentences and is already overly long.

Python is simply not an ideal choice for projects that need high performance multicore processing.

It is, of course, up to you to decide what high performance means, and the phrase is doing a great deal of heavy lifting here.
I do not foresee a well designed system of the character laid out in the project description actually needed to be 'high performance'. I continue to assert that while there is an objective performance loss with python, it would very often be suitable for the task you've laid out.

The fact that python can use more cores by spinning up more processes is technically correct but not relevant, that is not a high-performance multicore solution, that's a hack.

The actual inference backends are currently still in python and launched as sub-processes (however I'd like in the future to have a native C# execution engine available as an option - that's delayed to focus on more important things though)

I would also like to point out the irony in adopting the approach of multi-processing, but also claiming it is a hack.
My entire consternation comes from saying "python bad". All I am suggesting is that you say you feel C# is the tool you or your team prefer, rather than make broad - and mostly academic, and not real-world true - claims about python.

If you limit the rationale to something to the effect of "We want to expand C# options because that's what we know, and we can deliver the best experience that way given our expertise", I would have no further comment on the matter.

@mcmonkey4eva i would have been disappointed if you'd used the text as-is. i just wanted to give you more feedback and help nudge it in the direction you wanted.
what tazlin is saying is also unfortunately correct. the fact that you go out of your way to make performance comparisons is really going to 'upset' some people, who will then go out of their way to bring it up here, probably again and again.
it seems like a few charts of tests you've done would be helpful, but if that's out of scope, maybe just removing the mentions of python from the readme is the way to go. there's no point in bringing up a comparison if we can't see the test methodology or the results.

for additional data, reference this old stackoverflow answer about Python vs C# performance. simply put, out of the box, Python doesn't perform as well. but using tools like PyPy or especially cython will bring python's performance beyond that of C#.
but we don't have the tests, or the data. and so these questions/discussions will probably resurface until that is a settled question. thus is the nature of FOSS.

If you genuinely have robust, detailed, representative tests the whole discussion would be moot. As it is, if the readme says python is insufficient 'just because [insert buzzword here]', you're making a claim you're going to be disappointed to try and defend.
Avoid the python vs c# performance language entirely, as your position is unimpeachable if it is limited to 'it's our choice and C# is what we know'.

As for specifics, statements like:

that language is simply insufficient to meet the performance goals of this project (ie to provide a very fast and responsive multi-user-ready multi-backend service),

Is

So broad as to be almost meaningless; relying entirely on buzz words which have no real objective basis, and there are counter examples where services do exist with those characteristics in python.
Not helpful in describing the actual reasons for choosing C# (which, presumably, is that you know how to leverage C# in that way, but you do not know how to use python that way, even though it is capable of it).

I see the offering up of python as a sacrificial lamb to try an justify other, unstated reasons. I see no need on your end to justify python being bad, just focus on why C# is a good choice for your team.

If you would like to help improve the phrasing of that explanation, that's welcome, but the aggressive response here is not needed.

It seems, by effectively misidentifying my comments as off topic, you are viewing my statements as personal attacks or unwarranted. They are neither, and I feel that my proposed solution is both reasonable and straightforward, and that I focused entirely on the ‘python vs c#’ false dichotomy that the OP had identified.

If you would like to help improve the phrasing of that explanation, that's welcome, but the aggressive response here is not needed.

If you would like to help improve the phrasing of that explanation, that's welcome, but the aggressive response here is not needed.

Neither I, nor the OP are being aggressive. You accused them of being so, and they openly admitted to not being. I offered a critique - common in the open source world - and I think you viewed it unnecessarily severely, as you did with the OP.

I’ll leave it at this, as to not derail. I hope you’ll consider my points.

So, update, it's finally doc-writing time, so - the Motivations are now in their own separate doc, have been expanded, and there's an explicit note of This document explains the reasoning behind some core choices for the design of the project. These are not necessarily sweeping statements, reasons to make the same choices, or even absolutely true facts - these are the reasons that choices were made, and nothing more. at the top.

i have an updated translation for your consideration, now that it is a separate living document:

This scroll of wisdom elucidates the mystical motives behind the cardinal decisions of our project's creation. These are not cast as unbreakable enchantments, compelling reasons for identical choices, or even incontrovertible truths from the Book of All-Knowing - these are simply the catalysts that steered our choices, no more, no less.
It's crucial to remember that reading this scroll does not bind you to a magical contract compelling you to follow our chosen path. Nor does it guarantee the same results if you embark on a similar journey, for every quest is unique, and every choice shapes a different destiny.
These words not as commandments etched in stone, but rather as a gentle recounting of the decisions that have shaped our endeavor. This recounting aims to offer understanding, not dictate your future actions. Venture forth with this in mind, and shape your path according to your own wisdom and insight.

But to be sincere, C# is of high performance than python in every facets.

please, no more arguing about it. because you're going to hear facts that disagree with you. and this will drag ON AND ON.
anyone who responds further here will receive a free block from me, and it will no longer be possible to do code review on my pull requests, or comment on any issues I open.
To respond, as you desired:
C# really isn't faster than Python, especially when using Cython.
Cython is higher performing than C#, as it's not DotNET.


Repo sync for protected CLA branch

The pull request is created from main638068284974392540sync_temp to main to fix git push error for protected CLA branch

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


Added atomizer logo to readme

Let me know if you think the image should be smaller.

I'll defer to @src-code on this but the size is quite large for the readme. Also there is a .DS_Store file that should not be committed.

Good point, will sort out the DS file and logo size some time today (UK time).

Really this logo is for Atomic CSS, not for Atomizer.  Though we don't really make the distinction very clear on the web site (acss.io), I suppose.  So I'm not sure we'd want to use the logo for Atomizer, but perhaps @renatoi or @thierryk think otherwise?

Ah, that makes sense. Would it be possible to get the name of the person who made the logo? I would like to give them credit for it.


Tone.js r10 *  addons/p5.sound.js:125 Uncaught DOMException: The user aborted a request.

I downloaded the latest version of p5 (v 1.4.1) and simply uncommented the script tag in the empty example. And this error appeared:

Tone.js r10 *
addons/p5.sound.js:125
Uncaught DOMException: The user aborted a request.

I'm using:

Windows 10 (v 21H1)
VSCode (v 1.65)
Microsoft Edge (v 99.0.1150.46 (Official build) (64-bit))

How do you add labels?

hi! we don't know what empty example you are referring to, but we tested the editor and p5.sound.js is working ~


npm run build with AntDesignVueResolver [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import '/home/project/node_modules/ant-design-vue/es' is not supported resolving ES modules

i have tried to set cjs to both true and false to build, but same error. using all latest version.
Components({
      // allow auto load markdown components under `./src/components/`
      extensions: ['vue', 'md'],

      // allow auto import and register components used in markdown
      include: [/\.vue$/, /\.vue\?vue/, /\.md$/],

      // custom resolvers
      resolvers: [
        // auto import icons
        // https://github.com/antfu/unplugin-icons
        IconsResolver({
          componentPrefix: '',
          // enabledCollections: ['carbon']
        }),
        // https://github.com/antfu/unplugin-vue-components/issues/202
        AntDesignVueResolver({
          cjs: false
        }),
      ],

      dts: 'src/components.d.ts',
    }),

error:
[vite-ssg] An internal error occurred.
[vite-ssg] Please report an issue, if none already exists: https://github.com/antfu/vite-ssg/issues
(node:186362) UnhandledPromiseRejectionWarning: Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import '/home/project/node_modules/ant-design-vue/es' is not supported resolving ES modules imported from /home/project/.vite-ssg-temp/main.mjs
Did you mean to import<EMAIL_ADDRESS>    at new NodeError (internal/errors.js:322:7)
    at finalizeResolution (internal/modules/esm/resolve.js:304:17)
    at moduleResolve (internal/modules/esm/resolve.js:731:10)
    at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:842:11)
    at Loader.resolve (internal/modules/esm/loader.js:89:40)
    at Loader.getModuleJob (internal/modules/esm/loader.js:242:28)
    at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:76:40)
    at link (internal/modules/esm/module_job.js:75:36)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:186362) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 17)
(node:186362) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

npm run dev works fine, using template from https://github.com/antfu/vitesse

I also have this problem
[vite-ssg] An internal error occurred.
[vite-ssg] Please report an issue, if none already exists: https://github.com/antfu/vite-ssg/issues
node:internal/process/promises:246
          triggerUncaughtException(err, true /* fromPromise */);
          ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Users/jason_liang/Documents/Code/suiji/suiji-webapp/webapp/node_modules/ant-design-vue/es/locale/en_US' imported from /Users/jason_liang/Documents/Code/suiji/suiji-webapp/webapp/.vite-ssg-temp/main.mjs
Did you mean to import<EMAIL_ADDRESS>    at new NodeError (node:internal/errors:371:5)
    at finalizeResolution (node:internal/modules/esm/resolve:416:11)
    at moduleResolve (node:internal/modules/esm/resolve:932:10)
    at defaultResolve (node:internal/modules/esm/resolve:1044:11)
    at ESMLoader.resolve (node:internal/modules/esm/loader:422:30)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:222:40)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:76:40)
    at link (node:internal/modules/esm/module_job:75:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}
 ELIFECYCLE  Command failed with exit code 1.
 ELIFECYCLE  Command failed with exit code 1.

npm run dev works fine, using template from https://github.com/antfu/vitesse

+1，我现在是使用SSR，使用unplugin-vue-components/vite和unplugin-vue-components/resolvers时，出现问题：

I had the same problem with primevue and vitesse
Vitesse also uses vite-ssg. Setting format to cjs in ssgOptions fixed my issue.
vite.config.ts:
...

  ssgOptions: {
    script: 'async',
    formatting: 'minify',
    format: 'cjs'
  },

...

im getting:
node_modules/.pnpm/ant-design-vue@3.0.0-beta.4_4f726de02e89ff745196f225ebb1bbcf/node_modules/ant-design-vue/es/index.js:1
import * as components from './components';
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at compileFunction (<anonymous>)

@KeremKoksal  I followed your advice but I have the same issue as @u007

Actually, I used
        AntDesignVueResolver({
          importStyle: 'less',
          cjs: process.env.NODE_ENV === 'production',
        }),

and the error above disappeared, but now I have another issue:
/.../node_modules/.pnpm/ant-design-vue@3.2.11_vue@3.2.37/node_modules/ant-design-vue/lib/style/default.less:2
@root-entry-name: default;
^

SyntaxError: Invalid or unexpected token
    at Object.compileFunction (node:vm:360:18)
    at wrapSafe (node:internal/modules/cjs/loader:1049:15)
    at Module._compile (node:internal/modules/cjs/loader:1084:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1174:10)
    at Module.load (node:internal/modules/cjs/loader:998:32)
    at Module._load (node:internal/modules/cjs/loader:839:12)
    at Module.require (node:internal/modules/cjs/loader:1022:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/Users/katiagg/stripe/sandbox-apps/tool-fees-calculator/node_modules/.pnpm/ant-design-vue@3.2.11_vue@3.2.37/node_modules/ant-design-vue/lib/col/style/index.js:3:1)
    at Module._compile (node:internal/modules/cjs/loader:1120:14)

@Kagigz can u try add less to your package?

I have this in my dependencies:
    "less": "^4.1.3",
    "less-loader": "^11.0.0"

I had to remove the AntDesignResolver altogether in order for my app to build.
Having a module with
import Antd from 'ant-design-vue'

import { UserModule } from '~/types'

import 'ant-design-vue/dist/antd.less'

export const install: UserModule = ({ isClient, app }) => {
  app.use(Antd)
}

imports the components globally and solves the issues.

on nuxt, i can specify transpile option, I'm not sure how todo it with this vitesses repo

Actually, I used
        AntDesignVueResolver({
          importStyle: 'less',
          cjs: process.env.NODE_ENV === 'production',
        }),

and the error above disappeared, but now I have another issue:
/.../node_modules/.pnpm/ant-design-vue@3.2.11_vue@3.2.37/node_modules/ant-design-vue/lib/style/default.less:2
@root-entry-name: default;
^

SyntaxError: Invalid or unexpected token
    at Object.compileFunction (node:vm:360:18)
    at wrapSafe (node:internal/modules/cjs/loader:1049:15)
    at Module._compile (node:internal/modules/cjs/loader:1084:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1174:10)
    at Module.load (node:internal/modules/cjs/loader:998:32)
    at Module._load (node:internal/modules/cjs/loader:839:12)
    at Module.require (node:internal/modules/cjs/loader:1022:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/Users/katiagg/stripe/sandbox-apps/tool-fees-calculator/node_modules/.pnpm/ant-design-vue@3.2.11_vue@3.2.37/node_modules/ant-design-vue/lib/col/style/index.js:3:1)
    at Module._compile (node:internal/modules/cjs/loader:1120:14)

I have the same problem with Astro (


can load an old version of buffer

from an issue in pbkdf2

I think one of the issues is that safe-buffer requires the buffer package however since buffer is not specified in the safe-buffer package.json there's no constraint on the version that will satisfy it. So if another package is already using an older buffer release then safe-buffer won't pull a later one. Some of the older buffer packages releases do not support alloc.

I think the point is that Buffer should remain unconstrained - with browserify opting for buffer the dependency.

This was fixed by #12 and released as 5.1.0.


Adding UI to GitHub and Slack Username Lookup

Background
As the proof of concept for querying Slack usernames, GitHub usernames and email addresses of users has been completed and demonstrated, we now want to attach a UI to the metadata API to view this information in a more user friendly way.
Value
By giving the users an interface to query usernames, we open up access to both those with technical knowledge and those without. It also enables us to get a quick feedback loop when presenting the initial UI design to the consumers, before having to dedicate more time to building up the security side.
Questions / Assumptions
We are keeping the UI within the same repository/application as the API for now - until we know there is a true demand for this product and the need to hit the API routes directly.
We will be using the Python Flask and Jinja2 framworks to build the UI.
This card also includes going back to the users for feedback on the completed UI.
Acceptance Criteria

[ ] UI Completed
[ ] Prototype fed back to users
[ ] Documented the findings from the users

Reference
How to write good user stories

Basic search functionality now working as expected on the UI. Users can search via Slack username, GitHub username or email.
Now moving on to build a dedicated search results page.
Also removing the dropdown to search by each category - will add logic to determine this directly in the app

Now up and running:
https://operations-engineering-metadata.cloud-platform.service.justice.gov.uk/home

Prototype completed and demoed to the team. An additional branch has been created on the application (just called "additional-features" for now) demonstrating where we could potentially take this thing.
If we do include other services as part of the information displayed, this document may be handy to refer back to.
Next step with this is to create some new stories to help identify where to go next with this project.


Proposal changes

Project Abstract
This is a update for previous grant PR.
Application Checklist

[x] The application template has been copied, renamed ( project_name.md) and updated.
[x] A BTC or Ethereum (DAI/USDT) address for the payment of the milestones is provided inside the application.
[x] I have read and acknowledged the terms and conditions.
[x] The software delivered for this grant will be released under an open-source license specified in the application.
[x] The initial PR contains only one commit (squash and force-push if needed).
[x] The grant will only be announced once the first milestone has been accepted.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Miljan Milidrag seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks @MilGard91. Could you please also adjust the price to account for the missing functionality and sign the CLA?

Hi @alxs, price is adjusted and I signed the CLA.

@alxs I have just contacted Kuba to schedule another meeting, so we can solve this faster.

I think the identity activities are the most important and useful part of the project, so I would suggest to split the price between M1 and M3 60:40, rather than the 92:8 split you are proposing. As far as I can see, the archive issues currently holding you back are already being worked on?

I agree. I have updated the cost ratio between M1 and M3

You did not update the cost ratio, you just raised the total price. What makes you think we would support raising the price by more than a third without any extra deliverables?

You did not update the cost ratio, you just raised the total price. What makes you think we would support raising the price by more than a third without any extra deliverables?

You propose that we reduce the price of the first and second milestone vs third in 60:40 so that first 2 milestones are worth 20700$ and the 3rd milestone is worth 13800$?

You propose that we reduce the price of the first and second milestone vs third in 60:40 so that first 2 milestones are worth 20700$ and the 3rd milestone is worth 13800$?

Since M2 is unchanged, I would leave its price as is, but shift more of the payment from M1 to M3.

You propose that we reduce the price of the first and second milestone vs third in 60:40 so that first 2 milestones are worth 20700$ and the 3rd milestone is worth 13800$?

Since M2 is unchanged, I would leave its price as is, but shift more of the payment from M1 to M3.

It would be amazing if you can write numbers down that you think are good for each milestone so we can fix this faster.
Milestone 1: xxx$
Milestone 2: xxx$
Milestone 3: xxx$
Tnx!

You propose that we reduce the price of the first and second milestone vs third in 60:40 so that first 2 milestones are worth 20700$ and the 3rd milestone is worth 13800$?

Since M2 is unchanged, I would leave its price as is, but shift more of the payment from M1 to M3.

Updated.


Add websocket ping variables

Resolves #1904.
Adds WEBSOCKET_PING_TIMEOUT and WEBSOCKET_PING_INTERVAL config values. This is my first contribution to Sanic.  I couldn't find where the existing websocket config values were being set on the WebSocketProtocol. Please advise if I missed something. Added a test to ensure all config values present when WebSocketProtocol created.

I'm confused how adding text to the untracked .rst doc files lowered test coverage: https://codecov.io/gh/huge-success/sanic/commit/bcc13178ea96c8fd587abeaa0bedd290db7b0820


Document error handling

What's a MessageFailure?
How do they get turned into a response if uncaught?
How do I log them?
How do I customize them when decoding fails?

Possibly related to #1081 ?

Yes, but yours is better.  Closing this one.


Backport of fixes to 7.6.3

Fixes

#25802
#25781

@bot-gradle test RfR

I've triggered the following builds for you. Click here to see all build failures.

ReadyForRelease build

@bot-gradle test this

I've triggered the following builds for you. Click here to see all build failures.

PullRequestFeedback build

@bot-gradle test and merge

I've triggered a build for you. Click here to see all failures if there's any.


Placeholders in sprintf function is not replacing correctly

Current

Warning after checking

Wrong auto fixing

Current version  b394904

@ravinderk The unit tests I wrote against the develop branch all pass, but fail when added to the 0.10.0 tag you have as your current commit. Whatever the issue was, it looks like it's already been fixed. Please check out the develop branch and run your code against that.

Closing as duplicate of #698 which was fixed in #710


Add the method to the data we return to the dashboard and the REST API

This adds the http method to the dashboard and the REST API.
This is similar to the change that went into appmetrics for the summary table:
https://github.com/RuntimeTools/appmetrics-dash/pull/153
and the REST API:
https://github.com/RuntimeTools/appmetrics-dash/pull/155

Codecov Report

Merging #79 into master will increase coverage by 0.34%.
The diff coverage is 96.15%.

@@             Coverage Diff              @@
##             master      #79      +/-   ##
============================================
+ Coverage     58.64%   58.99%   +0.34%
- Complexity      161      162       +1
============================================
  Files            26       26
  Lines           948      956       +8
  Branches         85       85
============================================
+ Hits            556      564       +8
  Misses          359      359
  Partials         33       33

Impacted Files
Coverage Δ
Complexity Δ

...a/com/ibm/javametrics/analysis/MetricsContext.java
95.16% <100%> (ø)
14 <0> (ø)
:arrow_down:

...java/com/ibm/javametrics/analysis/MetricsData.java
100% <100%> (ø)
14 <0> (ø)
:arrow_down:

...com/ibm/javametrics/client/HttpDataAggregator.java
96.22% <100%> (+0.67%)
15 <3> (+1)
:arrow_up:

...com/ibm/javametrics/analysis/MetricsProcessor.java
90.9% <75%> (+0.09%)
31 <0> (ø)
:arrow_down:

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 bca517c...39decec. Read the comment docs.


Hey, more mimir stdlib!

Also the implementation of Search was completely wrong, so I've fixed that now.

Looks like literally everyone has a broken implementation of Search that was only revealed by adding these tests.  We're going to have to turn off their tests.

@djspiewak once all the Search tests are marked as pending (or realistically, skipped) for the other connectors, then this should be ready for merge.
Can you also open an issue for each connector that has a broken Search?

Four more integration tests enabled, yay!


Dynamically joining and leaving channels

Hi @ryanwinchester, thanks for your hard work and sharing your Twitch IRC library. I am wondering if you have any advice on getting an already running bot to smoothly join and leave channels? I tried coming up with my own solutions but it resulted in failure (probably because of my limited knowledge). Any advice on what I am doing is even possible right now would be appreciated.

@talk2MeGooseman I need to add the join function to TMI. https://github.com/ryanwinchester/tmi.ex/blob/main/lib/tmi.ex#L26
It will dispatch a message to ChannelServer which can dynamically join channels, but it is rate-limited because Twitch rate-limits channel joins.

Available in v0.5.1
iex> MyBot.join("channel")
iex> MyBot.part("channel")

Awesome, thanks for the information and quick turnaround. Right now I am actively using your package for my twitch extension Stream Closed Captioner to send reminder messages to the chat with more complex ideas in the future, and this addition will fuel that idea.
I got lucky that sending messages directly to the chat doesn't actually require joining the chat.


package golang SDK with a separate go.mod file and a lower version than the main project for better backwards compatibility

If we want to manage an older go version; the best way to do this is to copy shared resources like utility functions and entities and maintain them under the SDK folder.
This will duplicate the code, but it will ensure that the SDK will have the same functionality with an older go version.
Why Copy Utilities and Entities to the SDK Folder
Module Independence: By copying the necessary utilities and entities into the SDK folder, you ensure that the SDK is a fully independent module. This independence is crucial for maintaining different Go versions and for users who will import your SDK as a standalone package.
Version Consistency: When utilities and entities are copied into the SDK, you guarantee that SDK users will always get a consistent set of functionalities that work with the SDK's Go version. This prevents potential compatibility issues that could arise if the root project's utilities evolve separately.
Dependency Management: It simplifies dependency management for SDK users. They don't need to import or be aware of the root project's structure or dependencies.
Avoiding Circular Dependencies: If the SDK depends on the root folder and the root folder depends on the SDK, you create a circular dependency. Copying necessary components into the SDK avoids this problem.
Clear Boundaries: It establishes clear boundaries between what's part of the SDK and what's part of the main project, making it easier to maintain and update each part independently.

Note to self:

I'll try with go 1.19; if it does not work, I'll move with 1.20, 21, 22 etc.

Done.


upgrade test framework OS disto versions

https://github.com/longhorn/longhorn/issues/3045
Signed-off-by: Mohamed Eldafrawi<EMAIL_ADDRESS>

@meldafrawi see if need to backport to 1.2.x and 1.1.3.


Extend data access API

[x] getter for number of degrees of freedom trixi_ndofs_*
[x] getter for primitive variables trixi_load_prim
[x] change trixi_load_cell_average to only compute averages for a specified variable
[x]  tests for trixi_ndofs*
[x]  tests for trixi_load_prim

Related #43

Say I want to stay as close to Trixi.jl as possible and have read
https://trixi-framework.github.io/Trixi.jl/stable/conventions/#Cells-vs.-elements-vs.-nodes
would there be any place in libtrixi where "cell" should be used?

Great! Thanks for your hints!
This is now totally cell-free. And totally breaking.

Thanks for reviewing @sloede !
PackageCompiler is still failing. I had to discard my plan to resolve this via #207 because there seem to be some new issues.
It would however be great to merge this anyway.


Where is RPE used?

I've read the supplement describing the details of the recurrent positional encoding (RPE).
However, I cannot seem to find the code which RPE is implemented and used.
Would the authors kindly point out where the implementation of RPE is in the released codebase?

@killawhale2 Please find the code of RPE in line 215 to 221 of model/transformer_v2.py


'proj' keyword error

Trying to setup on linux, getting the following errors;
Downloading CCA...
Extracting CCA...
Installing CCA...
Moving model data to directory...
Traceback (most recent call last):
File "/home/ashton/Treetop/PROJECTS/LVC_2016/ucvm-17.2.0/lib/python3.5/site-packages/ucvm-17.2.0-py3.5.egg/EGG-INFO/scripts/ucvm_run_tests", line 104, in
sys.exit(main())
File "/home/ashton/Treetop/PROJECTS/LVC_2016/ucvm-17.2.0/lib/python3.5/site-packages/ucvm-17.2.0-py3.5.egg/EGG-INFO/scripts/ucvm_run_tests", line 67, in main
model = UCVM.get_model_instance(options["model"])
File "/home/ashton/Treetop/PROJECTS/LVC_2016/ucvm-17.2.0/lib/python3.5/site-packages/ucvm-17.2.0-py3.5.egg/ucvm/src/framework/ucvm.py", line 202, in get_model_instance
UCVM.instantiated_models[model] = getattr(new_class, found["class"])()
File "/home/ashton/Treetop/PROJECTS/LVC_2016/ucvm-17.2.0/lib/python3.5/site-packages/ucvm-17.2.0-py3.5.egg/ucvm/src/model/velocity/gridded_velocity_model.py", line 103, in init
self.out_proj = pyproj.Proj(self.config_dict["proj"])
KeyError: 'proj'
any clue?

This is fixed in the development branch and will be merged into master shortly.


for ai in mc.find(query).limit(0).items(): ... returns all documents; I would expect 0 docs

perhaps the code should use -1 as special value to mean "all", not 0, which should be a valid limit

EDIT:
sadly, this matches behavior of mongo shell, eg:
db.tnimongo.find().limit(0)
returns everything...
also mentioned here: http://devblog.me/wtf-mongo
closing


set foreground/background per display selection and highlight

Thank you for the fine extension. May I make a request please. When I select an error message in the build output the red foreground is almost indiscernible from the now darkened background. I would find it very helpful if the foreground/background can be specified upon each: display selection and highlight. Thank You Kindly Best Wishes Cheerios

I had the same problem. I changed the colors in the Visual Studio Fonts and Colors dialog. You'll need to select the Output Window from the drop down as pictured.


LineLense not displaying function signature

Describe the bug
When trying to enable LineLense, signatures are not displayed. I already tried several combinations, enabling and disabling CodeLens as well and still not working.
To Reproduce
Background Services is enabled.
Enable reference code lens is enabled.
I also noticed that in some cases it works and is some others it doesn't based on the lenght of the file. Attached a document with both cases, the file is the same, first case is the full file, not working, second section is a shorter version of the very same file and it works:
Working and not working.docx
Scneario 1:

Scneario 2:

Scenario 3:

Plugins installed: I removed a bunch of plugins for testing at a point that ionide was the only one. Then I just installed the minimum I need for now:

VS Code User configuration:
{
"FSharp.smartIndent": true,
"editor.suggestSelection": "first",
"vsintellicode.modify.editor.suggestSelection": "automaticallyOverrodeDefaultValue",
"gitlens.currentLine.enabled": false,
"git.confirmSync": false,
"editor.renderIndentGuides": false,
"git.autofetch": true
}
Expected behavior
Signature should be displayed in the same next to the function declaration.
Environment (please complete the following information):

OS: Win 10
Ionide version: 4.0.6
VSCode version: 1.36.1
mono / .Net Framework version: 4.7.2

Additional context
Two week ago it was working, last week at some point stop working but didn't paid much attention to it and I'm not sure what version was installed when stop working.

I was having same problem. Finally started from scratch with fsx file and it worked. slowly added back code and for some reason when I use TypeShape it breaks, any ideas?

@vmendivil  I tried on your sample file (in the docx) and can't reproduce, copy pasting in an fsx file give LineLens so there is something more creating the bug.
If there is an error in the developer tools view of vscode it would be really useful (Or some more specific setting you suspect are creating the problem)

Same issue here.
There are error log message in the F# output:
[Error - 11:38:09] Request textDocument/documentSymbol failed.
  Message: File 'c:\temp\test.fsx' not parsed
  Code: -32603
[Error - 11:38:15] Request textDocument/documentHighlight failed.
  Message: No symbol information found
  Code: -32603

My test.fsx looks like this:
let x = "34"
type T = Hurz

F# config:
    "FSharp.saveOnSendLastSelection": true,

Extension infos:
Name: Ionide-fsharp
Id: ionide.ionide-fsharp
Description: F# Language Support
Version: 4.0.6
Publisher: Ionide
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=Ionide.Ionide-fsharp

No line lens or code lens, but hovering over symbols shows correct tooltip infos.

Hey @vbfox
I just resume this today and I kind of get use to work again without the quick references of the signature in VSCode.
I tried to reproduce the issue in a different laptop and I get the same results.

In a fsx, if you copy the full code, it won't display the signature as in Scenario 1, if you delete all the code from line 22 up to the end of the file, it will start displaying the signature of the function.
Code with code beyond line 22:

Code without code beyond line 22:

Ass soon as I delete code beyond line 22, function signature appears on the editor.
Not sure if this is the log file you need but I see a bunch of errors related to ionide.

Console log:
Console log.txt
Hope that helps, let me know if I can provide anything else.


Some armour is incompatible with Mo'Bends

Just like Void-Thaumaturge
test in TC6-Beta5 & Mo'Bends V-0.22.1

OK Got it


'Unfortunately, chrome has stopped' every time I open this email

App Version: 5.005
Chrome version: Samsung build, 42.0.2311.111
Raw email: https://gist.github.com/DanielHeath/b1ce95e25fa7b0aa5d8d
Every time I open this email I get the message "Unfortunately, Chrome has stopped"
The chrome logs indicate there's a java.lang.SecurityException in readException:1472, file Parcel.java.
Exception message is 'Unable to start activity ComponentInfo' ... ChromeLauncherActivity ... Uid 10021 does not have permission to uri content://com.fsck.k9.attachmentprovider/<guid>/1415/RAW

I can't reproduce this. But I'm guessing it's because of the <iframe> element.

It's trying to load the attachment content as the source of the iframe. src=3D"cid:external_0"
There's no way we'd want to support this at email open. We should be stripping iframes on privacy grounds at any rate. If it's crashing Chrome/WebView that would be a Chrome bug to my mind. Maybe it was fixed on @cketti's device?


Optimizing

What do you guys to do optimize the final output? Even after trimming down a lot of unused vars (colors, etc), the generated base output is 13k lines at 180kb+. Just curious if there's a way to turn off helpers I know wouldn't end up using as a place to start.

Have you tried using something like https://github.com/purifycss/purifycss ? It scans your input and completely removes any unused selectors from the output.

That's in my "things to try" list, but there's a bit of complication involved in bootstrapping it, and there's always a risk of Purify missing something and stripped out required selectors and rules.

If you're using Laravel Mix, you can enable purifycss with a quick option:
mix.whatever()
    .options({ purifyCss: true })

As long as you aren't doing anything really out of the ordinary, it's surprisingly smart about checking the right files. Works with Blade, single file Vue components, etc.
THAT SAID, it has a pretty significant bug in that it doesn't strip CSS classes that contain non-standard characters (like our colons everywhere) and it also doesn't strip classes that end in numbers, so in my experience it wasn't that useful with Tailwind. Hopefully they fix that.
The main strategy we have right now is just simplifying your config. The biggest wins you'll get are in removing unused colors, spacing utilities, and using fewer breakpoints if you don't need 5 like we offer out of the box.
You can control which colors are available per utility as well, so you don't need to have your entire color palette available as backgrounds, borders, AND text colors.
Same deal with spacing; there's a good chance you can remove a bunch of negative margin utilities for example.
In the near future, we plan to modularize the utilities a lot more, so that instead of just doing @tailwind utilities, you could do this sort of thing:
@tailwind utilities/background-colors;
@tailwind utilities/border-widths;
@tailwind utilities/flex-wrapping;
// etc.

This would make it easy to straight up exclude any categories of utilities you aren't using.
In addition to that, those individual imports would never apply hover or responsive variants, so you could instead have fine grained control over what utilities have those variants and which don't:
@responsive {
    @hoverable {
        @tailwind utilities/background-colors;
    }

    @tailwind utilities/border-widths;
}

@tailwind utilities/flex-wrapping;
@tailwind utilities/z-index;

@responsive {
    @tailwind utilities/text-sizes;
}
// etc.

This would give you really fine control over the size of the generated file, at the cost of a lot of manual work of course. It would also let you make utilities hoverable (and focusable soon) that we opted not to make hoverable by default.
I don't think we will ever provide the degree of customization to do things like "only create these padding sizes for the left side and not the right side" or "only make these 2 padding sizes responsive".
Now all of that said, I don't think even the default configuration's output file size is actually a huge deal in practice. Even with the bazillion colors and breakpoints we provide, Tailwind is only 27kb minified and gzipped.
Compare that to a random site you use every day like for example GitHub, whose minified and gzipped CSS is 95.6kb, or DigitalOcean which comes in at 76.2kb, or Dribbble which is 75.3kb (I didn't even cherry pick these, just literally the first three sites in my bookmarks bar that I tried.)
Basically any image you ever serve is gonna be bigger than Tailwind's output, and users are only ever going to download it once until you deploy a new version, so personally I don't think it's worth sweating too much.
We are still committed to providing more ways to optimize the output size and it's something I check every time we change the framework in any way, so it's never going to get out of hand (ask @reinink, he is sick of hearing me talk about file size) but I do recommend trying not to sweat it too much. In my experience from a workflow perspective, it's way better to have more utilities than you need than it is to prematurely optimize and find yourself dicking around in the config file all the time basically writing new CSS because you deleted classes you weren't using yet but find yourself needing two weeks later.

ask @reinink, he is sick of hearing me talk about file size

It's true. While I very much value keeping the file size as small as possible, I'd hate to limit the framework as a whole because we think 25kb (minified) is too big, when in reality it isn't (or we simply don't know).
Maybe a good next step is to do some research into what impact a 25kb file will have, compared to a 15kb file, compared to a 40kb file. And then compare this to the average filesizes being used by most websites today.
I just don't want to burn pointless time and energy chasing something that doesn't matter. Micro optimizations are a productively killer.

I just did some tests where I removed breakpoints and reduced the color palette, here's what I got:

5 screen sizes
4 screen sizes
3 screen sizes
2 screen sizes
1 screen size

Full color palette (83 colors)
27.6kb
22.1kb (80%)
16.6kb (60%)
11kb (40%)
6.8kb (25%)

Half color palette (42 colors)
17.3kb (63%)
14.5kb (53%)
11.6kb (42%)
8.7kb (32%)
5.7kb (21%)

So if you can get away with fewer breakpoints or colors, that will definitely make a big difference.
We try to ship with an extremely generous amount of values in the default config just because we don't want you to have to edit it for prototyping purposes. Much better to trim the fat after your site is built and design has stabilized than to optimize prematurely I think, and even then 27.6kb doesn't worry me too much personally.

Totes! I agree with you. This was way more info than I expected :) nice work.

On Nov 2, 2017, at 7:05 PM, Adam Wathan<EMAIL_ADDRESS>wrote:
I just did some tests where I removed breakpoints and reduced the color palette, here's what I got:
5 screen sizes	4 screen sizes	3 screen sizes	2 screen sizes	1 screen size
Full color palette (83 colors)	27.6kb	22.1kb (80%)	16.6kb (60%)	11kb (40%)	6.8kb (25%)
Half color palette (42 colors)	17.3kb (63%)	14.5kb (53%)	11.6kb (42%)	8.7kb (32%)	5.7kb (21%)
So if you can get away with fewer breakpoints or colors, that will definitely make a big difference.
We try to ship with an extremely generous amount of values in the default config just because we don't want you to have to edit it for prototyping purposes. Much better to trim the fat after your site is built and design has stabilized than to optimize prematurely I think, and even then 27.6kb doesn't worry me too much personally.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@adamwathan One thing I noticed is if I want to use @apply in a Vue component I have to include @tailwind utilities; in every component I want to use it in. I noticed this would increase the css build size with every component that imported the Tailwind utilities. Any ideas how I could mitigate that?

@syropian, looks like a solid bug report, actually—I think the expectation is that @tailwind utilities; should only ever only import once, but after trying it myself, with each new @tailwind utilities; call, CSS jumps in line count by around 14,713 (based on a vanilla tailwind install).

@syropian @dstrunk I'm not sure if this is a common usecase.
But do you really need the full utilities in your JS-Component?
I always place the minimal amount of CSS needed for a component to work in the component itself.
The rest of the styles goes into a boring old css-file on a project level.
If you add the utility-classes to the components html directly that no problem.
You have them in one place and do not need to adjust them many times for the same component.
So I'd not use @apply at all and just drop the utility-classes in my html.
If you want to change the style => just change the html (you need to do that only at the one place) and you're good to go.

@psren Yeah, it's not a huge issue, I could of course extract anything I'd use @apply on into a separate component, sometimes I'm just lazy 😅

@syropian Yeah the issue is of course Tailwind can't @apply classes that it can't find, and it only knows to look in the current set of styles for classes to mix in.
I really don't know much about how style tags in Vue components work so I'm not sure what options there are for making it work the way you'd want.
One idea that comes to mind is writing some sort of PostCSS plugin for marking a section of CSS to be deleted and throwing that very late in your PostCSS chain:
<style>
@strip {
  @tailwind utilities;
}

.foo { @apply .bg-purple; }
</style>

Something like that could make the utilities available in the CSS at the time Tailwind is looking for them, and then strip them later.
I don't want to commit to taking this on as a Tailwind feature, but that would be an extremely easy PostCSS plugin to write if you wanted to get your feet wet with it 😊

@adamwathan That's a pretty cool idea! I can survive being more diligent about extracting things into Vue components for now, but I'll definitely consider a custom PostCSS plugin if it ends up becoming a pain point for me.

@adamwathan the @strip is not that easy because it has to search the HTML-Template of the component for used classes, too.

Just had another thought - has anybody tried yet exporting critical css yet for above/fold content?

It looks like a tailwind user has forked purifycss to make it work with tailwind's "special characters" in classes : / etc.: https://github.com/tailwindcss/tailwindcss/issues/137#issuecomment-342668417

Checkout PurgeCSS
The author recently made changes to work with Tailwind syntax. It has a webpack plugin and works well with Laravel Mix.
I have a few examples on a Medium post here:
https://medium.com/@AndrewDelPrete/using-purifycss-to-remove-unused-tailwind-css-classes-173b3ee8ee01

In the age where all developers are optimizing delivery of content for mobile, I think getting PurgeCSS or PurifyCSS to work with TailwindCSS is a must, especially for small to medium websites.
The framework at 27KB alone is bigger than most small to medium website's gzipped CSS file (by quite a margin).
Tailwind is a really nice concept and it's been nice testing stuff on it. But it is really hard to justify using TailwindCSS when the gzipped size is still so big. I feel the documentation should push users to implement PurgeCSS and PurifyCSS (or even a built in function) to filter all unused css classes in the final output.

@pxwee5 It's a lot smaller once you change the default color palette to be the colors you are actually using. We provide a lot out of the box to make it a nice getting started experience, but personally I don't think measuring the framework based on the intentionally bloated version we put on CDNs for prototyping is super fair.
If you reduce the number of breakpoints and colors to match what a framework like Tachyons provides for example, now you are down to under 15kb.
I recommend measuring the size of your own Tailwind generated CSS, not the default. You'll find it's probably smaller than Bootstrap when you use your own color palette instead of the big one we provide as an example.
It's also worth keeping in mind that your CSS isn't going to grow if you use a framework like Tailwind, at least not in the way it would with a traditional approach.
This post is a great example of how your CSS size will change over time on a project using a utility-approach:
https://medium.com/@johnpolacek/by-the-numbers-a-year-and-half-with-atomic-css-39d75b1263b4
All that said, 0.3 will be out this week that provides even more control over what's generated, and of course people are free and encouraged to use PurgeCSS to make things even smaller. We'll add documentation about that when we have time. This is a free open source project so no one is getting paid to work on this full time.

Added some documentation around this yesterday:
http://tailwind.dev/docs/controlling-file-size

The biggest issue with Purgecss  removal of dynamically generated classes. For example if I use twig template for basic pagination and want to dynamically add `class="pagination {{$state)}}" purgecss will not be aware of that. It would better  if we could redefine defaults of tailwind where if I set config value for  p-1, p-2, p-3, and p-4 it will not generate anything above that. Same thing would apply to colours, margins etc... This way we would have more control over what is generated.


WIP Introduce hyperscale style instance types

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

/cc @fabiand
First pass with introducing the newer style into the repo, thoughts would be appreciated.


Add inline mode support

See changelog.

How is the status on this one? I saw some related types commented out in the source code.

There's already inline mode support in master and recent versions


Upd supervisor

Hi @mereacre, I'm going to wait to review this until #154 is merged, most of the changes in this are in that too, if that's okay with you.


makewindows requires -w arg to be positioned before -s to work properly

$ bedtools makewindows -s 1 -w 50 -g assembly/genome.chrom.sizes | head
chr0    0       50
chr0    50      100
chr0    100     150
chr0    150     200
chr0    200     250
chr0    250     300
chr0    300     350
chr0    350     400
chr0    400     450
chr0    450     500
$ bedtools makewindows -w 50 -s 1 -g assembly/genome.chrom.sizes | head
chr0    0       50
chr0    1       51
chr0    2       52
chr0    3       53
chr0    4       54
chr0    5       55
chr0    6       56
chr0    7       57
chr0    8       58
chr0    9       59
$ bedtools --version
bedtools v2.25.0-10-g0686eea-dirty

Lame. I will look into this soon. Sorry for that.

This is now fixed in the repository. Thanks!

Thanks Aaron.
Daniel Vera, Ph.D.
Director
Center for Genomics and Personalized Medicine
The Florida State University
319 Stadium Drive
Tallahassee, Florida 32306-4295
phone:<PHONE_NUMBER>
email<EMAIL_ADDRESS>web: http://genomics.fsu.edu/
On Wed, Feb 3, 2016 at 6:25 PM, Aaron Quinlan<EMAIL_ADDRESS>wrote:

This is now fixed in the repository. Thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/arq5x/bedtools2/issues/325#issuecomment-179527697.[image:
Web Bug from
https://github.com/notifications/beacon/AFoQSqJOtXsZlC-jOHyxlxxwz4Hx5N3Rks5pgoQFgaJpZM4Gh3AM.gif]


Before this change:
$ time ruby test/run-test.rb -t SudachiSynonymDictionaryTest --verbose=important-only
Finished in 1.296801 seconds.
2 tests, 2 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0
notifications

real    0m1.964s
user    0m1.740s
sys     0m0.118s

After this change:
$ time ruby test/run-test.rb -t SudachiSynonymDictionaryTest --verbose=important-only
Finished in 0.010658 seconds.
2 tests, 2 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0
notifications

real    0m0.634s
user    0m0.455s
sys     0m0.092s

Thanks.

Thanks for your review!


Pass hit count into punch method in acts_as_punchable modals

Currently I'm having to add a customize method having Punch.create(punchable: self, hits: count). I would like to pass the count variable into https://github.com/biola/punching_bag/blob/master/lib/punching_bag/acts_as_punchable.rb#L26

My apologies that it's taken so very long for me to respond to this. I had been neglecting this project for a long time but I'm going to try to give it a little attention now.
This seems like a reasonable addition. I'll see if I can fit it in soon.

Just merged the PR to address this. I'll get a new gem version out soon.


v1.1

v1.1 update

Adding built-in Generalized Additive Model (GAM) estimating equations #20

To-do list:

[x] Add spline functions
[x] Add tests for spline functions
[x] Add design matrix generator for GAMs
[x] Add tests for design matrix generator
[x] Add estimating equations for GAMs
[x] Add tests for GAM estimating equations
[x] Add GAM reference pages
[x] Add GAM example in built-in page
[ ] Update examples to show full capacity of GAMs with delicatessen
[x] Add regression prediction functionality
[x] Add regression prediction docs
[x] Add regression prediction tests

One problem with the use of additive_design_matrix is that if only the number of knots are given, then it manually creates from the input. However, this can conflict when creating a design matrix for plots. The knot locations will be different in this second version, which will generate an incorrect plot.
I need to think of a way to prevent this (force users to provide the knot locations?)


Bug on update <IP_ADDRESS> (repeat component)

I tried to reopen a file I've made few weeks ago but now with version <IP_ADDRESS> this issue occurs. Maybe it has something to do with the repeat node (because I update the amount component in first frame).

This error prevents anything to display in my nodes and my preview.
How can I help you solve this issue? Do you need the file?

Oh, it's just a really bad typo on the code. I'll release the patch soon.

Should be fixed in <IP_ADDRESS> now


Add support for IDEs from Jetbrains.

Adds support for the code editor in Jetbrains IDEs.
This is explicitly not a theme for the rest of the UI, since that would (to my knowledge) require making a plugin.

Thanks @loudar after reviewing both PRs for IntelliJ I decided to merge #44 because it looks closer to me with respect to the colors in the reference screenshot. Now that the #44 is merged, I would be happy to review or have you collaborate with @annoyingmouse on any refinements you two can make to the color scheme from there. See also the VS Code and Sublime Text ports which provide useful reference for tokens.