Roadmap

Release Cycle

[x] Create a 1.0.0 release so we have something to put on the github.io page
[ ] Get Served

[ ] cdnjs -- need 100+ stars/watchers
[x] bower
[x] npm

Feature Set

[ ] Source ordering for columns (push/pull)
[x] Determine viability of including core JS (something jQuery ish? something else?)
[ ] Bones: Drop in plugins

Code Quality

[x] Refactor media query widths to be px (target device typical design widths, not sizes proportionate to font size)
[ ] Use vars to account for breakpoints so people can customize
[x] Refactor to use rem in buttons, form elements, etc
[x] Refactor to use non-percent gutters (rems or fixed px)
[ ] Refactor to replace hard coded values with variables

[x] Colors -2.0
[ ] Structural (margins, paddings, border widths)

Spin Up Community

[x] Docs

[x] Getting Started
[x] Grid System
[x] Utility Classes
[x] Misc (anything else that has custom classes, which is... buttons
[x] Rolling your own

[ ] Start rerouting issues from dhg/skeleton
[ ] Basic marketing/outreach:

[ ] Domain
[ ] Hosting
[ ] Facebook Page
[ ] Press Releases

[ ] Original icon
[ ] Original github.io site design
[x] Documentation in the wiki

Skeleton serves a nice niche by being so compact and laid back in its ambition. We don't really need another Bootstrap or Foundation.

Hey @enlore defiantly not barking up the wrong tree. This org was setup to continue the development of Skeleton, as it was originally written Vanilla CSS.
I really like the plugins idea, and think that could work with pretty much all of the sections, as a nice way of allowing people to use what parts of Skeleton they want.
There is currently a pretty general refactor going by the members of the org and we are also adding a few new things to it.
In the next couple of days, ill start making a whole bunch of adding to your list in the roadmap

Awesome.  Glad to see we're on the same page.  Anything you need help with as far as the refactor goes?

Here's something @fat wrote that's in the spirit of Skeleton for sidebar nav.  Not sure if it actually needs Skeleton, per se, but we should list it as an extension/plugin anyway.
https://github.com/fat/coffin
I've been doing a bunch of component centric design/dev lately for web ui and I've really fallen in love with the idea of designing things to work in an independent, interchangeable, composable way. Pick your pieces, drop them into place, et voila.
We could call them Bones.  Nav Bone connects to the Header Bone, the Header Bone connects to the Hero Image Bone, etc.

@enlore You are completely on the right track IMO. "Bones" will turn this project into an actual "Skeleton" Framework.

@enlore I also think that having a component based framework is a good direction to go. What kind of 'Bones' do you think we should have? I am thinking that a

Navigation
Header
Footer
Images (responsive image things)

Should we be having smaller ones??

Nav is a great candidate for our first set of Bones.  Good nav becomes great nav with a consummate increase the complexity of implementation, so providing a couple of Bones that implement well used patterns will (theoretically) benefit the framework's rate of adoption by giving people a couple of desirable options.
My go-to patterns for nav are basically these three:

Collapsing top bar, static (just like the regular responsive navbar that ships with Bootstrap)
Collapsing top bar, fixed (same as above but fixed in the viewport)
Side fly-out, just like Foundation's off-canvas

Beyond that, I'm really not sure.   We have the task ahead of us of drawing lines around what we think are appropriate units of work that we can do up front for people by creating Bones. Bootstrap and Foundation provide two catalogues of UI design patterns that we could cherry pick for essentials, but I really like the idea of sticking to a minimalist approach rather than trying to become an all encompassing solution.  Developing the framework as a loosely coupled collection of Bones does go a long way to keeping things minimalistic, granted.
I like doing a couple of variants on a Header Bone.  Maybe we could make bones for different media types.  Drop in components for responsive html5 video, images for sure, little audio player bars maybe.
Assuming you guys do a significant amount of front end dev for the web, what do you feel are pain points in your day to day layout work?  If you could pick one or two things to never need to code again, what would you throw in?

Video dropin isn't a bad idea, YouTube has a variety of minor overrides you need to make to stop the z-index freaking out.

:+1:

Facebook page in progress. We need an icon! https://www.facebook.com/skeletonframework

Under 'Get served' I think we should also add jsDelivr as a target, the original was hosted there too.
If we are going to add core JS my vote goes to Chibi.
It's 2.7k gzipped and supports down to IE6. I think more importantly it handles Opera Mini which is one the main browsers used in developing countries. Skeleton + Chibi would be great together in reducing data costs in those countries while still giving a modern web experience.

+1 to Chibi

Establishing "what this initiative should be" has been the bulk of discussion to date.  We've had some activity on a slack channel, but in light of your input, I think I'll be sticking to the issues pages from now on. I hadn't thought about the slack channel obfuscating our discussion to the rest of the community. Duh.
We've been kicking the idea around of paring off Skeleton with a small JS lib (I like the suggestion of Chibi quite a bit) and developing a small suite of drop in modules using them both.  That may be too much, though. I may move that out to a separate project, as it's pretty exeperimental.
I agree that we need to spend some quality time on the CSS itself and get that shipped.  My holiday/new year has been swamped, but the chaos has settled and I'm back to a regular routine.  I'm going to be doing just that (showing the CSS some love) today.
Thanks for the list of other libs out there, too. I'd been poking around for some to compare with, and I haven't seen some of these.

I'm feeling that.  When I first took interest in this, I didn't have a good concept of how crowded this space was.  I'm starting to think that the best value to be had here is to freshen up the core CSS, make it easy for others find again, and reroute issues here so people don't feel like it's abandoned.

As for Bones, I'm still exploring ideas about that.  Getting away from some kind of standard set of JS capabilities seems difficult. I have this beautiful fantasy world in my head where complex UI elements in the browser really can be dumped into a layout and there are flowers and they all play nice with each other and all the dev has to worry about configuring them correctly.

Ay, don't worry about dissuading.  Good projects stand on the merit of their utility and/or innovation.  Skeleton is hardly positioned to be innovative anymore, but it's utilitarian for sure.  Having explored this domain a bit more, I'm just not sure how interested I am in putting a ton of work into vying for market share. I do like the idea of connecting with the existing community, though.

Yeah, that's pretty much the conclusion I've come to.  The browser, as a platform, just isn't there yet. For now I'll just have to content myself with a small stable of comps for personal use.
You've got the idea, as far as Bones go. When I say config, I'm thinking behaviors.  Transition timings, what url to hit with with ajax, which columns should be sortable, event handling, etc. Frameworks like vue.js (I think mithril is in that realm, too?) are approaching that, but tend to just skip on the style/UI structure aspect. Looks like there's a good reason for that.

@enlore That is not a fantasy, but a dream. Dreams can become a reality. @orbitbot    I'm glad to see some interest in the project. We did have a slack channel, but it was decided it was not necessary at this time.
Concerning bones... I have given it a lot of thought. Bones started out as an idea of drop in components that could be used with skeleton. So, how are we supposed to implement this idea and give developers a wish to develop them?
@orbitbot You are thinking what I've come to a conclusion about. Bones should style existing components that are available to fit skeleton styling. One such example is the javascript pikaday. https://github.com/nathancahill/pikaday-skeleton
Concerning javascript... I love it. I want it. I would love to see a very minimal basic pure javascript library we could use. I think it should be very specific to start with and only give functions for buttons, forms, and menu items/links and maybe a few other small things that are used in most projects that skeleton would be good for. I think it is important to remember that a lot of the users of skeleton are beginners or novice developer and designers. I know that I found it when I first started out by searching google for a "skeleton css" file that I could use to help me learn. So, let's skip all the bells and whistles, and just give out enough to get people into the parade.

Ah, I see what you're saying. And well made components (in the loose, informal sense of the word) like Pikaday are designed not to rely on the presence of any other framework or lib.
Building something like a table component (as my ongoing goto example) that has sortable columns, can ajax its own data, etc, etc is cool, but making it a part of/integrate seamlessly with a lib like Skeleton as a dependency is more work than is worth doing since a) it didn't need to in the first place and b) people usually have their own thing going already anyway.
I like that notion of positioning Bones as adaptations of popular components, too.  Having a compendium of accessible, easy to use plug-n-play components (that don't rely on Skeleton but have been made to play nicely with it) to present to the community and smooth out wrinkles in people's dev workflow sounds like a good win for the project.
So ok, moving forward, let's see how many of these small, tight components we can find that would be a good fit for easy adaptation. We can kill a few birds with one stone:

highlighting quality components for the community at large,
thereby empowering experienced and new devs alike with good tools
differentiate a bit from some of the other frameworks, further justifying continued development on Skeleton

That'll will help keep the focus of Skeleton being a super light, minimalist starting point for a project. "Download Skeleton, customize it to suit your needs, and then maybe look at these Bones we've adapted for ease of use".

Just commenting to say I love the idea @enlore. I like Skeleton for its focus on minimalism, and I think this is a great way to expand the ease of using it. In general, I think it's commendable to push for including only what you need for a project. That can be achieved in part by providing some examples of components that work well and fit the philosophy, and encouraging further development of similar tools.

At work we could probably skip at least 60 % of bootstrap

That's absolutely the reason I found Skeleton in the first place.
Thanks @J-Hood. Gotta shout out to gld and orbit, too, though.  For being the first OSS project that I try to take a role of responsibility in, having smart people to hash it out with is super handy.
I'm glad the idea is appealing. I think there's value, in its own right, in collecting that list in the first place.
I'm going to start another issue collecting suggestions from the community at large for small, tight, decoupled components to nominate as Bone candidates.

Quick question, if I may: how usable is branch 2.0 at the moment?

The css itself should be perfectly fine. We don't have any significant changes to the core css (apart from one potential fix to the spacing of columns that I'm working on) planned for 2.0. The big ideas for a 2.0 version have more to do with build process and tweaks to the source code from which the css is created.

Thanks :)

Continuing conversation from #27.
@oltmannsdaniel Keeping the lib small is a core tenet of our philosophy with the project. To that end, I'll suggest instead that you create an extension project that uses the core Skeleton styles to create your list of features. Check out the conversation that's evolved around the idea of doing a set of Bones.
The idea is that the core Skeleton CSS focuses on a set of minimalist features (layout structure, a bit of color, typography, and normalizing/improving the styles of various elements e.g. form inputs), and then Bones build on those base styles to implement more complex elements like navbars, tabbed navigation, button groups, embedded video and audio, sliders, modals, etc.
Those elements are complex enough to stand on their own as projects in no small part because any one project won't require all of them. It's nice to be able to pick and choose, mix and match the things you'll need especially given our focus on mobile first.
Will you pick one of the features you've listed (such as nav), put it together, and make a PR to the Bones project linking to it? You'll see there's a checkbox project already listed there that can serve as an example project for you to base your own off of.

@enlore @oltmannsdaniel check out https://github.com/gld1982ltd/skeleton-ui and feel free to rip the CSS apart into bones. A lot of work done. Thanks to the original authors.

Cool. Looks like some good stuff. I'll check it out.

Next steps for Skeleton
More minimal. Heh.
Please consider this a brief Request for Comment. I'll let it sit here for a bit (maybe a week) and then start in on implementing.
Let's evolve Skeleton.
I think it's time to segregate the components into easy to access chunks
I find myself just grabbing the grid and typography by themselves more often than not. A couple of you have expressed a similar pattern of use. v1.2.0 needs to move a few things around and provide a simple way to get any combination of the core parts on demand. People who want the whole thing can still get it, and people who want just a couple of the components can get them just as easy.
Let's do the thing where you go to the Skeleton site, click on "Get Skeleton", and fill out a simple form requesting only the pieces you want.
When you check boxes next to grid,typography, and buttons, you'll be downloading a single CSS file that contains just those components. Or you can ask for grid, util, forms, and panels to just get a single CSS file with those components.
To facilitate this, the build processes will build out all possible combinations of the core components as listed below. This will happen at build time whenever we bump the version and make a new release, so the different concatenated together combinations of the core components will just be sitting there ready to download. Not even going to worry about having this stuff built out on the fly as people ask for it. Keeping it simple means (I think) that we can just host all the versions for download on the github.io page.
The Bones
Here are the six core components of the system as it stands, pared down slightly.

Grid
Buttons (interact-ables that aren't form elements)
Forms (inputs, textarea, select, fieldset, etc)
Typography

Body copy (p, h1 - h6, span, some helper classes like .t-sm, .t-lg, .t-left, .t-right, .t-center, .t-bold, etc)
Anchors
Lists
Tables
Code

Utility classes (.u-pullLeft, .u-pullRight, .u-displayNone, .u-displayBlock, .u-hidden, u.-visible, .u-imgResponsive, etc)
Content (panels, wells, alerts, cards, anything that isn't typography)

Implementation Notes
Six Bones (listed above) means 64 possible combinations of the different component parts. Simple enough, the build system will run the various CSS files through the postcss process and poop them out. Then we'll just have the build script jam 64 different concatenations of said parts together and save them with a dumb number scheme or the names of the bones, like grid.css, grid-forms.css, grid-buttons.css, grid-forms-buttons.css, etc. Stick a header at the top of each CSS file that lists the components that are present, and there you go. Time for :cake:.
This will necessitate paring down the core css files, and probably some fiddling to make sure that the variables set up in the root file are still used properly, etc.
At download time, a simple set of checkboxes are read and the requesting client is offered a download named skeleton.css of the particular concatenated set of Bones dictated by the form.
The Point of This Proposal
Keep the CSS simple and keep Skeleton super easy to use, just make it a bit simpler to get exactly the parts of Skeleton you actually want when you want them.
Most of the other "modular" css frameworks I've looked at require multiple file downloads to piece together the components you want, or they have big forms that you can use to tweak every detail about the build. The latter pattern seems prevalent among the big players like Bootstrap (I use Skeleton so as to avoid using the big frameworks), and the former doesn't do much to satisfy my desire for a minimalist approach.
How do you feel about all of this?
This is all pretty opinionated, so let me know what yours is.

Any utility classes you use often that you think would be cool to have here?
Any sweet new CSS knowledge you'd like to drop on us to improve the framework?
What do you always add or fix, and do you think we should add/fix it as part of the core?

A Word on the Idea of Bones
After all this thinking about and working with front end development tools and tech (and learning from other people's suggestions and advice), I've come to appreciate that less is more. A few good, simple tools will do the job, and if I need something fancy I go find it as a one off requirement for a given project and use it.
So instead of doing Bones as extensions to the core, let's treat the core css files as the Bones. That seems a fitting use of the Bone metaphor, and frees us up to use this org to catalog cool front end goodies rather than try to maintain a bunch of them that "just drop in" to the core CSS.

Just wandering over from the original repo (long unmaintained). I love the idea of "Bones".  I often use Skeleton just for the grid. Love it. I think having the option to download separate core components is a good thing. At the same time keeping everything simple to work with, simple to understand, simple to use. Dead simple.
Thanks for all your work thus far!

@Gusbenz my pleasure.
@everybody:
Ok, take a look at #55, give me some feedback, and we'll go from there.

Check this out: https://github.com/skeleton-framework/skeleton-framework.github.io/pull/9
Super simple method of hosting all of the combinations of the bones as 'builds' and generating a link to download a custom build on request.

Please consider this a brief Request for Comment. I'll let it sit here for a bit (maybe a week) and then start in on implementing.

my two cents regarding the build system, I hope it's not too late.
Background: my use case with skeleton framework is the following:
For each project where I use skeleton framework:

customize the look and feel in a forked branch
use in the main project as a git submodule
customize the skeleton build script based on the project's need (inside the project's branch in my forked repo)

I understand some users may simply want to download a vanilla skeleton framework build, for quick usage.

Some feedback:

Here are the six core components of the system as it stands, pared down slightly.

The six proposed bones make sense to me.

Six Bones (listed above) means 64 possible combinations of the different component parts.

Would the build process going to stay efficient / quick, and will it be possible to easily tweak it not to trigger the full 64 combinations build, whenever I just need one build in my project?
Also, is there really an important demand on partial / custom builds?
If I may, I would suggest to consider the approach used in d3.js. It's super easy to install parts of the library (bones), and to get the full build also.

What do you always add or fix, and do you think we should add/fix it as part of the core?

In my limited usage of skeletong, nothing is missing, and everything works really nice 💯
Thanks :)


refactor: replace Composition -> Experience in public interfaces

Purpose
Stop using outdated terms in the SDK
Approach
-> Replace use of term Composition with Experience in

types.ts:

CompositionComponentNode -> ExperienceTreeNode
CompositionTree -> ExperienceTree
Composition -> ExperienceFields
CompositionEntry -> ExperienceEntry

constants.ts

IncomingEvents.CompositionUpdated -> IncomingEvents.ExperienceUpdated

-> Mark old types as deprecated
-> Replace use of deprecated types across the monorepo. Includes there types that were previously deprecated.

Maybe this console log is worth renaming?

I know this ticket is primarily about Types, but I wonder if it's worth also renaming word composition in tests?

Yes, I can open another PR for this, but I want to get the public facing changes out of the way first, so I didn't spent too much time on the tests.


Read env variables for LDAP over TLS

Add functionality to read some environment vars to enable LDAP over TLS, specifically:
AUTH_LDAP_START_TLS
AUTH_LDAP_CA_CERT_FILE

Will make a PR.

@messersc what is the status here? done?

Deployed on internal instance already. Closing.


App Header: user menu should be regular weight, not bold

Acceptance Criteria:
Popover User menu in site header should be regular weight.

@ArakTaiRoth let me know if you have any questions.


bug on indexing?

https://github.com/PacktPublishing/Deep-Reinforcement-Learning-Hands-On/blob/a307a952bb914a1b5a43b7c92b7237ca28d88d28/Chapter14/06_train_d4pg.py#L79-L86
Hello Maxim,
Your book is really helpful for us to immediately implement D4PG, but I am wondering if the index for l and u should be modified to be as follows:
proj_distr[eq_dones, l[eq_mask]] = 1.0
proj_distr[ne_dones, l[ne_mask]] = (u - b_j)[ne_mask]
proj_distr[ne_dones, u[ne_mask]] = (b_j - l)[ne_mask]
Thanks for any clarification.

Hi!
Yes, you're right, those indexations are now needed for code to work properly, but I'm not sure why it worked fine before :). Probably some subtle change in numpy indexation. I'll implement and commit the change you've proposed.
Thanks!

Sorry for looong wait. Fixed by PR13: https://github.com/PacktPublishing/Deep-Reinforcement-Learning-Hands-On/pull/13


Failing to parse model template with latest Mixtral Dolphin versions

System Info
running with docker 1.4 container, args:
        "--model-id",
        "TheBloke/dolphin-2.6-mixtral-8x7b-GPTQ",
        "--quantize",
        "gptq",
        "--max-total-tokens=32768",
        "--max-input-length=30000",
        "--max-batch-prefill-tokens=32768",
        "--sharded=true",
        "--port=8080"

causes an exception to be thrown due to the model template:
2024-02-05T11:00:44.045948Z  WARN text_generation_router: router/src/main.rs:327: Invalid hostname, defaulting to <IP_ADDRESS>
thread 'main' panicked at router/src/infer.rs:99:18:
called `Result::unwrap()` on an `Err` value: Error { kind: SyntaxError, detail: "unexpected `.`, expected assignment operator", name: "<string>", line: 4 }

---------------------------------- <string> -----------------------------------
   1 | {{ bos_token }}{%- set ns = namespace(found=false) -%}
   2 | {%- for message in messages -%}
   3 |     {%- if message['role'] == 'system' -%}
   4 >         {%- set ns.found = true -%}
     i                   ^ syntax error
   5 |     {%- endif -%}
   6 | {%- endfor -%}
   7 | {%- if not ns.found -%}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No referenced variables
-------------------------------------------------------------------------------

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Information

[X] Docker
[ ] The CLI directly

Tasks

[X] An officially supported command
[ ] My own modifications

Reproduction
simply try to start tgi instance with any dolphin-2.6-mixtral-8x7b will result in this error.
Expected behavior
model is loaded and served

Just ran into this myself today. Reverted to 1.3.4 and it is running ok.


Adding algorithm to check if number is prime or not.

My first contribution to this repository contains algorithm to check if the given number is prime or not.
Small description on how I have optimized the logic:
Reduced all possibilities of a number which cannot be prime.
Eg: No even number, except 2 can be a prime number, hence we will increment our loop with i+2 jumping on all odd numbers only.
If number is <= 1 or if it is even except 2, break the loop and return false telling number is not prime.

Use a simpler file name like ‘check_prime.cpp’
See #807 for how to comment your code. People should be able to read and learn from your code
Please done say ‘most optimized algorithm’ if there is no research publication backing your claim

@kvedala Modified the code as per the changes you have suggested.

@kvedala Modified the code as per the changes you have suggested.

Please see the files changes in #807 - The comment blocks, and structure is per the doxygen standard. link to actual file
GCC suggests -
$ g++ math/check_prime.cpp -o test -Wall
math/check_prime.cpp: In function 'int is_prime(int)':
math/check_prime.cpp:8:23: warning: suggest parentheses around comparison in operand of '&' [-Wparentheses]
    8 |     } else if (no & 1 == 0) {  // otherwise if other even numbers, return false

Also, if you want to optimize further, you can have the line# 12 loop condition to go only till (I*i) < no - again, this already exists in some of the existing code in the repository.

Can I close this pull request ?

Can I close this pull request ?

It will get closed once the pull-request is merged. But for this to happen, the reviewers would have to first approve.
And for that, could you please make the necessary corrections as requested?
Thank you.

@kvedala is it good enough to merge with master?

@ayaankhan98 Is it okay to modify the code as per @Panquesito7 ?

@ayaankhan98 Is it okay to modify the code as per @Panquesito7 ?

i will not suggest to modify this current implementaion as per directed by @Panquesito7 because whatever he suggested is a navie approch and is slow, but there is no problem in having both approches in the repository if you wish you can make a PR with this navie approch sepreatly

@ayaankhan98 Is it okay to modify the code as per @Panquesito7 ?

i will not suggest to modify this current implementaion as directed by @Panquesito7 because whatever he suggested is a navie approch and is slow, but there is no problem in having both approches in the repository if you wish you can make a PR with this navie approch sepreatly

Yes, no need to change the algorithm in this implementation. it is good as is.

when I merge the new master to my fork, my auto tools formatted the code for me 😃 - cdb9766f7a4d3313a7d4aa140268e7b57d16c7a1
and when I reviewed the changes, noticed that the int main() function does not return an int. The fix will go to #805


[Bug]: aisingapore/sea-lion-7b-instruct fails with assert config.embedding_fraction == 1.0

Your current environment
python 3.10 vllm 0.3.3
🐛 Describe the bug
https://huggingface.co/aisingapore/sea-lion-7b-instruct/blob/main/config.json
WARNING 03-20 04:11:30 tokenizer.py:64] Using a slow tokenizer. This might cause a significant slowdown. Consider using a fast tokenizer instead.
Traceback (most recent call last):
  File "/h2ogpt_conda/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/h2ogpt_conda/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/entrypoints/openai/api_server.py", line 237, in <module>
    engine = AsyncLLMEngine.from_engine_args(engine_args)
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 625, in from_engine_args
    engine = cls(parallel_config.worker_use_ray,
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 321, in __init__
    self.engine = self._init_engine(*args, **kwargs)
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/engine/async_llm_engine.py", line 366, in _init_engine
    return engine_class(*args, **kwargs)
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/engine/llm_engine.py", line 120, in __init__
    self._init_workers()
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/engine/llm_engine.py", line 164, in _init_workers
    self._run_workers("load_model")
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/engine/llm_engine.py", line 1014, in _run_workers
    driver_worker_output = getattr(self.driver_worker,
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/worker/worker.py", line 100, in load_model
    self.model_runner.load_model()
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/worker/model_runner.py", line 84, in load_model
    self.model = get_model(self.model_config, self.device_config,
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/model_executor/model_loader.py", line 79, in get_model
    model = model_class(model_config.hf_config, linear_method)
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/model_executor/models/mpt.py", line 260, in __init__
    self.transformer = MPTModel(config, linear_method)
  File "/h2ogpt_conda/vllm_env/lib/python3.10/site-packages/vllm/model_executor/models/mpt.py", line 211, in __init__
    assert config.embedding_fraction == 1.0

Some documentation for additional context https://huggingface.co/docs/transformers/main/en/model_doc/mpt#transformers.MptConfig.embedding_fraction.
I wonder why a gradient scaling parameter has an assertion. @WoosukKwon, as the author of MPT support could you shed some light on this?

@pseudotensor did you install vllm via this method? https://github.com/aisingapore/sealion/tree/vllm/vllm

I didn't, wasn't aware of it.

It should work with this, there are some discrepancies between the MPT and SEA-LION architectures.

That repo is too old to be useful, too many missing features.

@pseudotensor can we close this as stale/solved?
Or are you still experiencing/caring about the issue?


Explain race mode in tooltip.

In the tooltip, describe what "Race Mode" is. Currently there is only an info about logs and seed. But what is race mode?

It's just that, it generates a rom which cannot be spoiled, for racing purposes. Doesn't change anything else.


Add logging type to UI config

High Level Description
This PR adds the logging configuration to the UI config so they can easily switch between the two logging back ends.
Related Issues

DCOS_OSS-645

Checklist for all PR's

[ ] Included a test which will fail if code is reverted but test is not. If there is no test please explain here:
[x] Read the DC/OS contributing guidelines
[x] Followed relevant code rules Rules for Packages and Systemd

Checklist for component/package updates:
If you are changing components or packages in DC/OS (e.g. you are bumping the sha or ref of anything underneath packages), then in addition to the above please also include:

[ ] Change log from the last version integrated (this should be a link to commits for easy verification and review): example
[ ] Test Results: [link to CI job test results for component]
[ ] Code Coverage (if available): [link to code coverage report]

PLEASE FILL IN THE TEMPLATE ABOVE / DO NOT REMOVE ANY SECTIONS ABOVE THIS LINE
Instructions and Review Process
What is the review process and when will my changes land?
All PRs require 2 approvals using github's pull request reviews.
Reviewers should be:

Developers who understand the code being modified.
Developers responsible for code that interacts with or depends on the code being modified.

It is best to proactively ask for 2 reviews by @mentioning the candidate reviewers in the PR comments area. The responsibility is on the developer submitting the PR to follow-up with reviewers and make sure a PR is reviewed in a timely manner. Once a PR has 2 ship-it's, no red reviews, and all tests are green it will be included in the next train.

Test failures are due to AWS API limits.

@spahl @adam-mesos @darkonie This is ready for review.

@mesosphere-mergebot bump-ee

We have a ship it label? Nice.


pull request for e2e test at 11/15/2016 13:56:12

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

optest/docs/updated_at.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Setup auto releasing on GitHub tagging

This should create a new release on PyPi when we create a new tag on GitHub.
Does anyone have opinions which one of our jobs we should use for the deployment? It seems like any of them would do

This is related to #340

Seems to work! No real way to test the auto-release stuff without making a release, so let's do an alpha of 0.6 when we're ready to test drive it.


Please re-enable CDF5 by default

Now that the CDF5 bug is fixed, please consider turning-on the --enable-cdf5 option to configure by default. That option was introduced in 4.5.0, and some distros are unaware of its existence, and as a result they ship netCDF with CDF5 disabled, which creates headaches all-around. See #930 for an example of what happened with conda-forge.

Easy enough, with the CDF5 issue corrected we can take care of this.


Error of metric  name use Chinese Text

Superset version
Windows 10  x64，python 3.6.1   superset 0.18.5
Expected results
metric name can use  The Chinese Text
Actual results
stacktrace:null
status:"failed"
error:"'utf-8' codec can't decode byte 0xbb in position 0: invalid start byte"
webui message：'utf-8' codec can't decode byte 0xbb in position 0: invalid start byte
Steps to reproduce
I writed Chinese text for sql Metric name in the Sqla Table Edit‘s  List Sqla  Metric，when run the query，it's
error：'utf-8' codec can't decode byte 0xbb in position 0: invalid start byte，
Request URL:http://<IP_ADDRESS>:8000/superset/explore_json/table/8/?form_data={"datasource"%3A"8__table"%2C"viz_type"%3A"big_number_total"%2C"slice_id"%3A37%2C"granularity_sqla"%3A"vip15"%2C"time_grain_sqla"%3A"day"%2C"since"%3A"1+year+ago"%2C"until"%3A"now"%2C"metric"%3A"积分余额汇总"%2C"y_axis_format"%3A".3s"%2C"where"%3A""%2C"having"%3A""%2C"filters"%3A[]}
Request Method:GET
Status Code:400 BAD REQUEST
Remote Address:<IP_ADDRESS>:8000
form_data:{"datasource":"8__table","viz_type":"big_number_total","slice_id":37,"granularity_sqla":"vip15","time_grain_sqla":"day","since":"1 year ago","until":"now","metric":"积分余额汇总","y_axis_format":".3s","where":"","having":"","filters":[]}
query:
"SELECT "积分余额汇总"↵FROM↵  (SELECT sum(vipxx.vip10) AS "积分余额汇总"↵   FROM vipxx↵   WHERE vip15 >= TO_TIMESTAMP('2016-07-16T10:01:14', 'YYYY-MM-DD"T"HH24:MI:SS.ff6')↵     AND vip15 <= TO_TIMESTAMP('2017-07-16T10:01:14', 'YYYY-MM-DD"T"HH24:MI:SS.ff6'))↵WHERE ROWNUM <= 50000"
How to fix the error，Help me please，Thk！

Please post the full stacktrace found in superset server logs, am pretty sure we already the same issue reported though.

Almost the same question. I need chinese legends on my plot. So I took chinese as my metric name. WebUI shows "'ascii' codec can't encode characters in position 160-161: ordinal not in range(128)". I have set the charset on db

SQLAlchemy URI
mysql+pymysql://XXX?charset=utf8
2.engine_params
{
"metadata_params": {},
"engine_params": {"connect_args": { "charset": "utf8" }}
}

I have the same problems,and addressed by https://github.com/apache/incubator-superset/issues/3136

I have the same problem,and addressed by #3136

@luciuschina #3136 is this very same bug :)

@xrmx sorry,https://github.com/apache/incubator-superset/issues/2554

Notice: this issue has been closed because it has been inactive for 270 days. Feel free to comment and request for this issue to be reopened.

Is this problem resolved?


Local build failure

Hi, thanks for sharing code. Would you consider adding some build instructions to the project?
I've tried to build it with xcodebuild -project 'Swift Shift.xcodeproj' CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO but this does not seems to be working, from the look of it, seems like the local dependencies are missing
Copy /Users/piotr/src/SwiftShift/build/Release/Swift\ Shift.app/Contents/Resources/ShortcutRecorder_ShortcutRecorder.bundle /Users/piotr/src/SwiftShift/build/Release/ShortcutRecorder_ShortcutRecorder.bundle (in target 'Swift Shift' from project 'Swift Shift')
    cd /Users/piotr/src/SwiftShift
    builtin-copy -exclude .DS_Store -exclude CVS -exclude .svn -exclude .git -exclude .hg -resolve-src-symlinks /Users/piotr/src/SwiftShift/build/Release/ShortcutRecorder_ShortcutRecorder.bundle /Users/piotr/src/SwiftShift/build/Release/Swift\ Shift.app/Contents/Resources
error: /Users/piotr/src/SwiftShift/build/Release/ShortcutRecorder_ShortcutRecorder.bundle: No such file or directory (in target 'Swift Shift' from project 'Swift Shift')

Hey! Sorry I'm new to swift/xcode and I have no idea how to build stuff from the terminal. I just use Xcode to build it, does that work for you?

Closing this one. Feel free to open it again.

@slashbeast in case you're still interested, this works for me:
xcodebuild -workspace Swift\ Shift.xcodeproj/project.xcworkspace -scheme Swift\ Shift


Added support for 'members' field of Group catalog model entity.

Added support for the 'members' field of the Group entity, allowing specification of direct members from the Group side of the relationship, plus tests to ensure that the field is not required (not present and empty) as well as ensuring that the values have the appropriate length (rejects empty strings and undefined values).
Added support to the BuiltinKindsEntityProcessor to generate the appropriate relationships.  Updated test to ensure that the expected relationships are emitted.
Updated documentation to reflect support for the new "members" field for the Group catalog model entity.
Closes #5072.

Also looks good, @Rugvip / @freben?

Nice!
As we merge this, I realize that there's one quirk to be aware of. The memberOf relation is defined to be transitive, in the sense that you are meant to express your membership upwards in all ancestor groups, if you want ownership to work throughout the hierarchy (not just for groups that you are an immediate member of - i.e. if something is owned by your entire department, you may want to see that as well as Owned). At the same time, in a large org you probably don't want to make it so that the org root has tens of thousands of member entries. The code here is supposed to help out with taking "shallow" spec refs and expanding them to "deep" relations. We may need to update that code to take this new spec field into account.


Add tool to use device as a heat source

This is a very risky idea, so I completely understand if it is not implemented. I had the idea for a tool that attempts to heat up the device battery as much as possible, to be used in extreme emergency situations where every bit of heat counts. Obviously this poses the risk of significantly damaging the device, but it is designed for life-or-death situations where it would make sense to sacrifice the device to save a life from freezing. Some things to research would be how effective this heat source would be, the best places to apply the heat source, the fastest way to heat up the device, and if such a tool would break any rules in app stores.

Hi, thank you for the suggestion. I have looked into this in the past and decided against it: #356


Split tokens into a separate crate

We should explore ways how to move smart_contract/default/tokens.rs into a separate crate that can be imported by both iroha_executor and iroha_client. The big problem to consider here is how to have that crate swappable because we want, not just default tokens,  but also user defined tokens to be provided by this crate.
The solution we find for tokens will be a foundation for creating executor_data_model crate which will contain all structures that are shared by iroha_executor and iroha_client such as custom expression system.
I somehow don't feel this is possible to do. I think that every executor will define it's own executor_data_model crate which will then be imported by the client. When a user creates their own executor, they will also make their own executor_data_model which can (but doesn't have to) re-export iroha_default_executor_data_model

so in essence we can define iroha_default_executor_data_model but users of iroha will have to define their own data model crates

I have a concern about swappable data model in general. Currently, probably the main reason to use an SDK is to safely build data model types. If data model is not static, then Iroha users (other devs) will have to build their own SDKs, which seems like a huge overhead.
Not entirely sure if my concern is 100% related to this issue.

Not entirely sure if my concern is 100% related to this issue.

Yes, your concern is related and valid

Regarding SDK problem I think we should provide support for default types as we do now. But if users will decide that they need some kind of expressions or anything else they should be able to combine our SDK and their own data model

closed as part of #4791


Make serial consume wrong input quicker

It can be delayed for a long time, by garbage containing line breaks?

There's a weird thing on Linux where serial output is being sent back, but not right away, so consumption speed might not be the issue.


chore: update nodeConfig for nitro 2.2.x

This PR updates prepareNodeConfig so it uses the latest node configuration format as of nitro v2.2.2 (including 2.2.3 and 2.2.4)
Most changes are just relocating the configuration since the structure has changed since 2.1.x. However, one more configuration option has been added: node.delayed-sequencer.use-merge-finality: false,. This configuration makes the delayed sequencer to not wait for full finality on the parent chain before sequencing messages coming from the parent chain, making it more comfortable to work with cross-chain messages.
As an example, the orbit-setup-script always waits for the cross-chain messages to be executed on the orbit chain. Without this parameter, the orbit-setup-script takes around 40 minutes to fully execute, although it's likely to timeout while waiting for the createTokenBridge retryable execution.
NOTE: Coordination is needed to merge this PR along with the change in the Orbit setup-script and the update of the Orbit SDK package in the Orbit deployment UI.

In the block:
  if (chainConfig.arbitrum.DataAvailabilityCommittee) {
rpc and rest aggregators should not be the same port. RPC is 9876 and REST is 9877
https://docs.arbitrum.io/node-running/how-tos/data-availability-committee/deploy-a-das#step-3-deploy-the-das


Execute cell and get completions that require jupyter test is failing

Pylance changed their completion behavior/parsing.
Failure looks like so:

This is caused by pylance not returning DataFrame completions. See upstream issue here:
https://github.com/microsoft/pylance-release/issues/2302

No such test anymore


Fix runtimeCaching urlPattern strings

Fixes #139.
Sorry for the refactor but I thought it would make more sense to test the runtimeCaching string generation functionality in isolation.
I'm not sure if you want to use the NODE_ENV===test check for exporting 'private' functions for testing or another option (underscore prefix?).
Cheers

I signed it!

Much appreciated, @jwagner! 👍


Date component supported by Polymer

Hi guys
I'm working with Polymer 1.0 but can't find any Date picker component.
Do we plan to have it in future or any alternative solution?
Thanks in advance
Tung

See https://github.com/Polymer/paper-elements/issues/20


Update Partner#Show Page

Summary
It would aid diaper banks to know how many families, children, and the zip codes that their partner agencies serve. We should pull this and make it available for our diaper bank users to easily see and review. This information is available on the partner application and will need to be pulled from there.
There are several ways this could be done. We could pull from the partner app and store the data in the partner table. We could pull and cache the data to redis. We could push the data from the partner app on changes. And so on. Whatever method you decide to go with please have a member of the team sign off on it first. Something to consider is that we will likely also display the number of families/children on the partner index page at some point as well as needing this information for creating end of year reports for the diaper banks.
Criteria for Completion

[ ] Create an endpoint on the Partner app to expose this information. Note: This will require changes and a PR to that application.
[ ] Determine a strategy for storing and keeping that information up to date.
[ ] On the partner#show page display Number of Families Served:, Number of Children Served:, and Zip Codes Served by this Partner:

Determine a strategy for storing and keeping that information up to date.

For this would it be possible to utilize the multiple database support which came with Rails 6? I've never used it before, but I thought it might help.
https://rubyinrails.com/2019/03/25/rails-6-activerecord-multi-db-connection-switching/

Something like this would have to happen in stages right? I'd be happy to commit to creating an endpoint in the Partner app that exposes this information.

We might want to have a discussion on the best way to proceed with this -- we could use the multiple database model or we could use APIs like we've been doing since we have somewhat established patterns for that.
I think if we go with the API route it may make sense to change from an ask system to a tell system. So, rather than having the diaper app ask the partner app each time what the details are of a various partner, have the partner app tell the diaper app the current state of things on each update/change and store that on the diaper app.

Hey @seanmarcia, I like the API route you mentioned, especially since that's the already established pattern.

Closing this issue due to work done in - https://github.com/rubyforgood/diaper/projects/17 . Opened https://github.com/rubyforgood/diaper/issues/1623 to explore the idea of showing the list of zipcodes instead of just the number of zipcodes served.


Need support both kind of private key

Currently wallet only support private key without 0x
When enter private with 0x it's not recognized

Fix in #322


Policy and Governing Components

I just wanted to open a discussion to understand the current thinking about applying policies and governance to Dapr components in K8s. Right now, in K8s, AFAIK once a component definition is deployed it is open to be consumed by any Dapr instance deployed to the cluster as per the loader. Loading all components to every daprd instance is clearly not going to work in an actual use case. Do we already have a plan for addressing this or do we need to discuss it further?

What are the problems you see with loading the components for every sidecar?

I guess I'm looking at it from the point of view that a component is an authorized connection to an external system and I'd be trying to encourage the principal of least privaledged. K8s namespaces can be used to isolate access to a certain degree but I think people would prefer more granualar access control over which specific apps can access which specific external systems (this is only an opinion). It feels analogous to using one big config for every app because it's easier to manage regardless of whether they need 80% of what's in it or not.


Fix GOMAXPROCS setup

Due to using sudo, GOMAXPROCS was not being set in the consul environment.  Kept getting the following upon startup:
WARNING: It is highly recommended to set GOMAXPROCS higher than 1

thanks


Let's stop resolving dependencies over HTTP and require HTTPS

Want to take over the Java ecosystem? All you need is a MITM!
The details in the blog post above describe my research over the past 4 months into the use of HTTP to resolve dependencies across the JVM ecosystem.
This vulnerability impacted the open source build infrastructure for organizations like the Apache Foundation, Eclipse Foundation, Jenkins, JetBrains, RedHat, ect...
One of the cases where I discovered this vulnerability was in the build infrastructure for some of Twitter's's open source projects. They were declaring jar dependencies using repositories over HTTP. Thus a MITM of their SBT build could have allowed for the malicious compromise of their artifacts. For this finding, I was awarded a bug bounty by their security team.
I believe that it's the responsibility of API authors, especially of build tools to help protect their users from careless security vulnerabilities like this.
As such, I've begun work on fixing this for all users of Gradle in this PR:
https://github.com/gradle/gradle/pull/9419
Additionally, I've opened an issue with the Apache Maven team about fixing this there as well:
https://issues.apache.org/jira/browse/MNG-6673
Similar work is being done by the Bazel team:
https://github.com/bazelbuild/bazel/issues/8607
Deliverables

[ ] Next minor release: Begin warning users about their use of HTTP to download dependencies.
[ ] Next major release: Force users to explicitly opt-out of the security offered by using HTTPS.

@JLLeitschuh Thanks for the report.
Since 2014 (https://github.com/sbt/sbt/pull/1507) sbt defaults to HTTPS for Maven Central downloads, but you're proposing that we force HTTPS for custom resolvers as well without an explicit opt-out?

@eed3si9n I'm suggesting that you fail if the user specifies http instead of https. They are allowed to opt-in to being insecure if necessary for their use case, but this should be explicit.
I believe that a majority of the cases where I found uses of http instead of https were either copy/pasted code or were fat fingered typos.

I believe that a majority of the cases where I found uses of http instead of https were either copy/pasted code or were fat fingered typos.

Searching GitHub for resolvers extension:sbt language:Scala, sorted recently indexed seems to back up your claim.
resolvers += Resolver.url("jetbrains-sbt", url(s"http://dl.bintray.com/jetbrains/sbt-plugins"))(Resolver.ivyStylePatterns)

resolvers += "Typesafe Releases" at "http://repo.typesafe.com/typesafe/releases/"

resolvers += "MimirDB" at "http://maven.mimirdb.info/"

in RC4, the new warning is appearing for my local Artifactory, which is what I always resolve everything from
perhaps I could/should configure my local Artifactory for https, but it looks like work. I'm also curious if I can suppress the warning
(or, idk, perhaps the warning ought not to appear at all when it's <IP_ADDRESS> or localhost?)

another thought about configurability: some users might want to go in the other direction and have the warning always be an error

another thought about configurability: some users might want to go in the other direction and have the warning always be an error

The plan is to remove HTTP support in sbt 1.4.0 by making it an error. At that point (or sooner) we would create -Dsbt.insecureprotocol=true or something like that.

@eed3si9n Out of curiosity, why make it a flagg instead of per-repository?
There are certain cases where companies may have internal mirrors without certs and they don't consider MTIM a threat inside their network, however all other repos must use HTTPS.
The approach that I'm taking with Gradle is to do per-repository. We are also making the intentional decision not to offer a build flag to disable the check as it makes it too easy to make the whole build insecure.
One other thing we're thinking about is ensuring that we protect against servers that redirect to an HTTP based repository and failing in those cases as well.

perhaps the warning ought not to appear at all when it's <IP_ADDRESS> or localhost

For gradle we don't warn on <IP_ADDRESS> which allows us to test the HTTP/HTTPS logic in a controlled way across our codebase and gives our tests an easy opt-out so we don't have to install a truststore for every test.

In sbt, the resolvers can come from machine-specific repository overrides, frequently used in behind-firewall environments - https://www.scala-sbt.org/1.0/docs/Proxy-Repositories.html
I will also think about per-repo opt-in.

For gradle we don't warn on <IP_ADDRESS> which allows us to test the HTTP/HTTPS logic in a controlled way across our codebase and gives our tests an easy opt-out so we don't have to install a truststore for every test.

That's good to know. That would solve Seth's issue.

I'm happy to see that SBT takes step to require HTTPS for public repositories, but I'd also appreciate a per-repo opt-in to HTTP.
We build in a walled network only accessible to employees and resolve all artifacts, internal or otherwise, through an in-house artifactory.  HTTPS isn't really necessary in this scenario, so I'd like to avoid the hassle of setting up certificates, etc.

I see that SBT 1.3.0 now warns about HTTP requests, recommending to switch to HTTPS or opt-in with .withAllowInsecureProtocol(true).  Thanks for this :+1:
However, we typically configure our proxy repository in ~/.sbt/repositories; as said before our proxy repository runs on HTTP because it's inside a isolated access-controlled network where MITM is no real-thread, so I'd like to opt-out from HTTPS.
But how can I do that in the repositories file?

+1 - we have the same situation as @lunaryorn and now see lots of warnings on a regular basis

But how can I do that in the repositories file?

I didn't want to rush a solution for repositories file change, and I haven't figured out what it should be done here. If I can figure out resolvers coming from repositories file, should they be exempted automatically, or should I somehow extend the syntax to allow opt-in?

Should they be exempted automatically

I would argue no. This puts us back at square one if you do this.

Should I somehow extend the syntax to allow opt-in

This is probably the most appropriate thing to do. You want to keep the opt-out per repository declaration.

I guess explicit‘s better than implicit in this case, so I tend to lean towards an explicit flag in the file. 🙂

I'd also settle for a global allow http flag, if that's not already been bandied around

@henricook As I said before, we made the intentional decision not to do this for Gradle:

We are also making the intentional decision not to offer a build flag to disable the check as it makes it too easy to make the whole build insecure.

Would a whitelist be a sensible compromise?
Instead of a global build flag use a comma separated list of urls to disable it for those urls, e.g.:
// explicit
-Dsbt.allow.insecure.protocol=sonatype.mycompany.com,repository.mycompany.com

I commend sbt pushing for secure defaults proactively. 👍
That said, the way this was implemented is very unfortunate. In our situation we have internal sbt-plugins which are still used by lots of projects which aren't using sbt 1.3.x yet (40+ at this point).
This puts us in the following situation:

Projects which are already using 1.3.x receive dozens of useless warnings for company-internal resolvers on basically every command.

Projects which are not yet on 1.2.x don't receive the warning, but if we upgraded the sbt-plugins to 1.3.x and added the .withInsecureProtocol(true) flag they'd now crash with NoSuchMethodError as the flag doesn't exist in 1.2.x.

It's basically a lose-lose unless we now drop everything, upgrade every last one of the 40+ projects to 1.3.x (which isn't always straightforward) and then upgrade the sbt-plugins to a new version with the flag only to have to upgrade all projects with the new plugin-version again afterwards.
We would highly appreciate a way to globally treat a company-internal resolver as secure even with http, so the constant warning-spam stops and we don't have to upgrade all our projects twice just to be able to silence these warnings.
Thanks for your time 🙂

I think that you can compile your code so that it checks the SBT version before calling withInsecureProtocol and the JVM won't crash with a NoSuchMethodError since the if check won't attempt to call the method that doesn't exist.

Thanks for the suggestion! I got it working for both 1.3.x and 1.2.x 👍
For other people who need a workaround in sbt-plugins:
  // in a sbt-plugin

  override def globalSettings: Seq[Def.Setting[_]] = Seq(
    // The resolver to get libraries from.
    companyResolver := {
      val sbtVersionValue = sbtVersion.value

      ("Company Release Repo Nexus" at "http://artifacts.company.com/content/groups/public")
        .allowInsecureConnection(sbtVersionValue)
    }
    // possibly do something similar for `publishTo`
  )

  /**
    * Needed to keep backwards compatibility with projects not on 1.3.x yet
    */
  implicit private final class MavenRepositoryOps(repo: MavenRepository) {
    def allowInsecureConnection(sbtVersion: String): MavenRepository =
      if (sbtVersion.startsWith("1.3."))
        repo.withAllowInsecureProtocol(true)
      else
        repo
  }

But how can I do that in the repositories file?

I didn't want to rush a solution for repositories file change, and I haven't figured out what it should be done here. If I can figure out resolvers coming from repositories file, should they be exempted automatically, or should I somehow extend the syntax to allow opt-in?

Any update for this?
We use nexus as repository proxy instead of use public repositories directly. So we need better support for internal HTTP-only repository.

I agree, I still can't take my SBT 1.2.8 CI setup with a repositories file that points everything to my internal mirror and upgrade it to SBT 1.3.8
I get a weird checksum issue first, but even after disabling checksums (safe, I know ;-) I still find that it tries to go out to the internet in situations where it wasn't before. I've given up again

Any update for this?

I was thinking about adding some changes for sbt 1.4.0. In other words, it hasn't been urgent priority to fix this and patch 1.3.x series since people should still be able to use sbt behind the firewall. Is this not the case?
Looking at the implementation, I think it would be similar to this commit https://github.com/sbt/launcher/commit/00f681a7121d73c598f41358e1158fa0169d5a60 where it added support for:
  ivy-repo: http://repo.example.com, [pattern], descriptorOptional

This could be extended to something like
  ivy-repo: http://repo.example.com, [pattern], allowInsecureProtocol
  maven-repo: http://repo.example.com, allowInsecureProtocol

I'm sorry I think, at least for my comments, this ticket has diverged into "I can't use an internal dependencies proxy/mirror with sbt 1.3.x like i could with sbt 1.2.8"
I do agree that being able to turn off the HTTP warning would be useful if you know what you're doing, and that some use cases do see genuine http use cases in the real world

With a standard sbt project without any customized resolver, I still have the following warnings:
[warn] insecure HTTP request is deprecated 'http://repo.typesafe.com/typesafe/releases'; switch to HTTPS or opt-in as ("typesafe-releases" at "http://repo.typesafe.com/typesafe/releases").withAllowInsecureProtocol(true)

Is it configured like this per default in sbt?

I am working within a company net, which is rigorously firewalled. Our Nexus repository proxies everything, including public repositories, and it would be a huge hassle for us to set that up with https.
As our repository is configured in the "repositories" file, I get these insecure warnings for every command on every project, which is quite a hassle.
Is there a solution in the pipeline to enable this? The "withAllowInsecureProtocol" method does not work in this time.

@eed3si9n is this fixed in 1.3.11? or is https://github.com/sbt/launcher/pull/75 only one piece of it?

@SethTisue sbt 1.3.11 should address the allowInsecureProtocol part that corporate proxy users have been waiting for.
1.4.x would pull out the HTTPS to close out this epic.

https://github.com/sbt/sbt/pull/5593 scheduled for sbt 1.4.0 will drop HTTP support out of box.

@eed3si9n Is there a public issue tracking the drop of HTTP support for http://repo.typesafe.com?
https://github.com/sbt/sbt/issues/4905#issuecomment-575803374

Oh wow, what isn't clear from #5593 to me is how I can keep HTTP, is there a flag? Or is it forced unsupported?

@JLLeitschuh not sure if there's an issue, but there was a blog post: https://www.lightbend.com/blog/lightbend-to-require-https-on-repos-starting-august-5-2020
@henricook use .withAllowInsecureProtocol(true)
@eed3si9n on Christmas 🎅, you wrote:

Currently there's no way to suppress the warning if you're using repository override

does that remain the case? because my local-Artifactory setup, which uses an ~/.sbt/repositories file, is http: based, will I need to fix that?

Nice, i hadn't seen this which should let me do that via a repository override file as well, so very nice :+1: https://github.com/sbt/sbt/issues/4905#issuecomment-636261825

Perhaps some repositories documentation improvements may be necessary, is this valid?
maven-proxy: http://infra-mavenproxy-stag.stag.svc.cluster.local:8000/repo1.maven.org/maven2/, allowInsecureProtocol ?

@SethTisue sbt 1.3.12 + launcher together add allowInsecureProtocol support to launcher configuration, including repositories file. This means that sbt launcher needs to be upgraded via SDKMAN etc for this feature to kick in.
@henricook Your definition should be ok. I'll try to update the docs.

Thanks, so the launcher isn't bundled with 1.3.12? For an average user like me does that mean waiting until 1.3.13?

The sbt 1.3.12 installer uses the new launcher, but many people don't reinstall sbt every time there's a patch release of sbt, and just change project/build.properties.

I see that SBT 1.3.0 now warns about HTTP requests, recommending to switch to HTTPS or opt-in with .withAllowInsecureProtocol(true). Thanks for this 👍
However, we typically configure our proxy repository in ~/.sbt/repositories; as said before our proxy repository runs on HTTP because it's inside a isolated access-controlled network where MITM is no real-thread, so I'd like to opt-out from HTTPS.
But how can I do that in the repositories file?

in repositories file，you can add config as name: url,allowInsecureProtocol
ref: https://www.scala-sbt.org/1.x/docs/Launcher-Configuration.html
eg.
[repositories]
local
nexus-private: http://private-example.com/,allowInsecureProtocol

This doesnt work1

I see that SBT 1.3.0 now warns about HTTP requests, recommending to switch to HTTPS or opt-in with .withAllowInsecureProtocol(true). Thanks for this 👍
However, we typically configure our proxy repository in ~/.sbt/repositories; as said before our proxy repository runs on HTTP because it's inside a isolated access-controlled network where MITM is no real-thread, so I'd like to opt-out from HTTPS.
But how can I do that in the repositories file?

in repositories file，you can add config as name: url,allowInsecureProtocol
ref: https://www.scala-sbt.org/1.x/docs/Launcher-Configuration.html
eg.
[repositories]
local
nexus-private: http://private-example.com/,allowInsecureProtocol

This doesnt work

@pmkyl Could you open a new issue for this please?


No DNS inside podman containers of gitea-actions-runner

Describe the bug
No Domain is reachable when the podman Container is started by the gitea-actions-runner service. Therefore all workflows fail.
Steps To Reproduce
Steps to reproduce the behavior:

Configure DNS, Podman, and forgejo-actions-runner like described in the wiki
Write a workflow
See it failing inside your forgejo instance because of missing dns

Expected behavior
Normal name resolution inside the container
Additional context
My forgejo-runner configurration:
{ pkgs, config, ... }:

{
  services.gitea-actions-runner = {
    package = pkgs.forgejo-actions-runner;
    instances.default = {
      enable = true;
      name = config.networking.hostName;
      url = "https://codeberg.org";
      token = "******************************************";
      labels = [
        "ubuntu-latest:docker://node:16-bullseye"
        "nix:docker://nixos/nix:latest"
        ## optionally provide native execution on the host:
        # "native:host"
      ];
    };
  };
}

My podman configuration:
{ ... }:

{
  virtualisation = {
    containers.enable = true;

    podman = {
      enable = true;
      # Create a `docker` alias for podman, to use it as a drop-in replacement
      dockerCompat = true;
      # Replace docker socket with podman
      dockerSocket.enable = true;

      defaultNetwork.settings = {
        # Required for containers under podman-compose to be able to talk to each other.
        dns_enabled = true;
      };
    };
  };
}

My Networking configuration:
networking = {
    hostName = "********";
    nameservers = [ "<IP_ADDRESS>" "::1" ];
    enableIPv6 = true;
    networkmanager = {
      enable = true;
      dns = "none";
    };

    dhcpcd.extraConfig = "nohook resolv.conf";
    resolvconf.useLocalResolver = true;

    firewall = {
      enable = true;
      allowedTCPPorts = [
        # config.services.headscale.port
      ] ++ config.services.openssh.ports;
    };
  };

My DNS configuration:
{
  services.dnscrypt-proxy2 = {
    enable = true;
    settings = {
      ipv6_servers = true;
      require_dnssec = true;

      sources.public-resolvers = {
        urls = [
          "https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/public-resolvers.md"
          "https://download.dnscrypt.info/resolvers-list/v3/public-resolvers.md"
        ];
        cache_file = "/var/lib/dnscrypt-proxy2/public-resolvers.md";
        minisign_key = "RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3";
      };

      # You can choose a specific set of servers from https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v3/public-resolvers.md
      # server_names = [ ... ];
    };
  };

  systemd.services.dnscrypt-proxy2.serviceConfig = {
    StateDirectory = "dnscrypt-proxy";
  };
}

Notify maintainers
@adamcstephens @emilylange @mweinelt @SuperSandro2000 @zowoq

Add a :+1: reaction to issues you find important.

I am extremely confident that this is because you set networking.nameservers = [ "<IP_ADDRESS>" "::1" ]; which podman discards because <IP_ADDRESS> in the container is the container itself and not your host's nameserver.
You can configure different nameservers just for podman. Please refer to its documentation instead.

I am extremely confident that this is because you set networking.nameservers = [ "<IP_ADDRESS>" "::1" ]; which podman discards because <IP_ADDRESS> in the container is the container itself and not your host's nameserver.
You can configure different nameservers just for podman. Please refer to its documentation instead.

When outputting the content of /etc/resolv.conf inside the container I get the following.
search dns.podman
nameserver <IP_ADDRESS>
options edns0 trust-ad

So it tries to use the dns server of the host propably.
Do I maybe have to open the port for it from the host to the podman network?

I am debuggin this for two days already
@emilylange of course I also tried setting nameserver to only the cloudflare ip
I reboot after every rebuild and before every test

In my experience any DNS server not in the network needs usually some custom config for containers to work. I would suggest to use tcpdump to debug until where the packet is roughly going and then iptables counters to know which rules drops it.

The problem was that even after switching from Podman to docker I still had podman networking settings enabled


bluescreen screen when using URL http://<IP_ADDRESS>:1880/ui

when using URL http://<IP_ADDRESS>:1880/ui I get a bluescreen while that URL should give me my nodered dashboard.
It did work when entering the URL https://www.google.com
It is exactly the same issue as reported by Dennis in
http://www.hardill.me.uk/wordpress/2016/11/25/auto-launch-webpages-full-screen-on-android/#comment-143720
kr
Jan

I've just pushed a new release to the Google Play store that should fix this. Please let me know if it works

Wow, super cool. It is working now. Thanks a lot. Jan
On Mar 11, 2017 15:57, "Ben Hardill"<EMAIL_ADDRESS>wrote:

I've just pushed a new release to the Google Play store that should fix
this. Please let me know if it works
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hardillb/AndroidWebAutoLaunch/issues/1#issuecomment-285871680,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQcJfjgZdMmiq85mmNYxVbXPsG8-iRsoks5rkrZcgaJpZM4MaKRm
.


transfer the origin of instrument frame to a body fixed frame

Hi everyone,
I'm trying to use dskx02 function of the spiceypy toolkit to work out ray intercepts with a dsk shapemodel. I'm able to use a rotational matrix to convert vectors defined in an instrument-based reference frame in a spacecraft to a body-fixed coordinate frame for a planetary body that is being observed. However I'm having trouble converting the origin of the instrument-based coordinate system to the body-fixed coordinate frame, as this point in space is an input required as a vertex for the incoming ray/ boresight vector from the instrument.
Perhaps I'm missing something trivial. Any inisights would be highly appreciated.
Cheers !

Hi there,
normally, the origin of the instrument-based reference frame (or coordinate system) is the
spacecraft it is mounted on. Therefore, a simple call to SPKPOS or SPKEZR should give you
the vector you are looking for.
If the instrument is mounted on a platform for which an SPK exists, then the instead of using the
spacecraft name, a call to SPKPOS or SPKEZR with the instrument name would give you the origin of the reference frame your looking for (assuming you have loaded that SPK where the position of
the platform is given with respect to the spacecraft center of mass).
Note that in both cases, you should use, as reference frame for the SPKPOS/SPKEZR, the body-fixed reference frame of the planetary body that is being observed. This vector will be in the reference
frame that you're looking for, and no transformation will be required.
Cheers,
Jorge

Thanks a lot for this insight Jorge, I did discover a new functionality of the spkpos/spkezr that it can compute the position of a reference frame too, with respect to a given body.


Use references for constraints & nodes in TrimmingHandle.

@wally-the-cartographer merge

Merge requested by authorized user cschuet. Merge queue now has a length of 1.


MNT: A little hardening of the auditing of Nodes

Description
Two measures to harden the auditing (a little bit):

Type annotate the Node's children to prevent setting invalid types.
Change all the tests that use loads to only load trusted types instead of using trusted=True

The latter is important because when setting trusted=True, the whole machinery of checking types is not executed, so any bugs that may be contained there will not be revealed. In particular, this shows that for persisting methods, we had a child with a str type and that would raise an error, i.e. so far, loading method types was not possible for users who passed trusted!=True.
Additional changes
As a consequence of the last point, the auditing code has been changed to accept str as type. Alternatively, we can make the change explained here:
https://github.com/skops-dev/skops/pull/338#discussion_r1156151738
i.e. not storing the method name in children.
Another "victim" of this PR is that the so far dead code of checking for primitive types inside of get_unsafe_set has been removed. This code was supposed to check if the type is a primitive type but it was defective. get_module(child) would raise an error if an instance of the type would be passed. We could theoretically fix that code, but it would still be dead code because primitive types are stored as json.
Another small change is to exclude the code in skops/io/old from mypy checks. Otherwise, we would have to update its type signatures if signatures in the persistence code change (as they did here).

Ready for review @skops-dev/maintainers


PHP error

I keep on getting PHP error

Make u sure install php

apt install php -y
pkg install php -y


Add error code device path not found

Signed-off-by: Meghna Singh<EMAIL_ADDRESS>

Can you add the test result for these changes ?

Result of pod describe for device-path not found
Meghnas-MBP:kubernetes meghna$ kubectl describe pod testpodrwo-dev-5987c475b7-gvvsq
Name:           testpodrwo-dev-5987c475b7-gvvsq
Namespace:      default
Priority:       0
Node:           <IP_ADDRESS>/<IP_ADDRESS>
Start Time:     Wed, 29 Sep 2021 10:40:22 +0530
Labels:         app=testpodrwo
                pod-template-hash=5987c475b7
                tier=frontend
Annotations:    <none>
Status:         Pending
IP:
IPs:            <none>
Controlled By:  ReplicaSet/testpodrwo-dev-5987c475b7
Containers:
  container-name:
    Container ID:
    Image:          nginx
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ContainerCreating
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /myvolumepathxyza from pvc-name (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-lbh6x (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  pvc-name:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  csi-block-pvc-good5
    ReadOnly:   false
  default-token-lbh6x:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-lbh6x
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason                  Age                From                     Message
  ----     ------                  ----               ----                     -------
  Normal   Scheduled               <unknown>                                   Successfully assigned default/testpodrwo-dev-5987c475b7-gvvsq to <IP_ADDRESS>
  Normal   SuccessfulAttachVolume  74s                attachdetach-controller  AttachVolume.Attach succeeded for volume "pvc-d8dbc560-3a8d-4a29-a39e-32c4491e528a"
  Warning  FailedMount             11s (x2 over 32s)  kubelet, <IP_ADDRESS>      MountVolume.MountDevice failed for volume "pvc-d8dbc560-3a8d-4a29-a39e-32c4491e528a" : rpc error: code = Internal desc = {RequestID: 37f3114d-832f-4500-8f15-f8d796fa32f6  , Code: DevicePathNotFound, Description: Device path '/dev/disk/by-id/virtio-02b7-8e019fca-ecc4-4' is not present, Action: List volume attachments by using `ibmcloud ks storage attachments --worker <worker-ID> --cluster <cluster-ID> | grep <volume-ID≥` If the volume is attached, open a ticket and select VPC for the Problem type. Otherwise, select IBM Cloud Kubernetes service Problem type.}
Meghnas-MBP:kubernetes meghna$


README.md: Fix link to plugins documentation

README.md: Fix link to plugins documentation

Thanks @alexbrand I like this change, would you mind doing it for the rest of the doc links in the readme?

Will do!


Encountered unexpected whitespace at [my repos]

When the project directory contains whitespace
$dotenv = Dotenv::createImmutable(__DIR__,'.env'); will not work. Here is the error
Uncaught Dotenv\Exception\InvalidFileException: Failed to parse dotenv file. Encountered unexpected whitespace at [my repos]. in ..\vendor\vlucas\phpdotenv\src\Parser\Parser.php:30 Stack trace: #0 ..\vendor\graham-campbell\result-type\src\Error.php(118):

That's not what's happening here. You have a syntax error in your .env file itself.

Thank you for this. Inside .env file, I could escape from SAVE_TO=C:/my repos to SAVE_TO="C:/my repos" and now it works perfectly.
This should be closed.


Obtaining data from predefined chunks and using it in world generation

All chunks in the world are generated by custom plane meshes created from script. The chunk on the right was generated from FastNoiseLite data and the chunk on the left was generated from a predefined PackedScene using Godot's TileMaps.

The idea is all the chunks generated from noise data are created first and then there is a small chance for a predefined chunk to randomly appear in the world and replace the randomly generated tiles with predefined tiles.
In the picture above you can see that the predefined chunk is the same size as the noise chunk. But the predefined chunk should be able to cover any number of chunks. This way artists created the predefined chunks are not limited to one chunk.
So far the predefined and noise chunk are both being created in separate meshes. But this will need to change. There should only be one mesh. The noise data should be generated first and then the predefined data should replace the noise data. Then and only then should the mesh be generated.
On the predefined branch you will find the above picture setup in this commit 61e6d5f8a50c782258e69975c6bfcd01e9ca83e4. In the commit after that b09a7c28474154a6ae3b63e802ff298bcad3d526 you will find that I have tried to experiment with saving / loading multiple predefined chunk data.

This picture shows the defined chunk scene now holds 4 chunks. Notice how the center chunk is to the bottom right of the editor origin. I thought it would be easier to keep track of where each chunk was by defining the center chunk here.
There is a script attached to this scene.
public partial class DefinedChunk : Node2D
{
    public List<TileLayerPredefined> TileLayers { get; } = new();

    public void Init()
    {
        foreach (TileMap tileMap in GetChildren())
        {
            var layer0 = 0;
            var sourceId = 0;
            var tileAtlas = tileMap.TileSet.GetSource(sourceId) as TileSetAtlasSource;
            var tileLayer = new TileLayerPredefined
            {
                Image = tileAtlas.Texture,
                ZIndex = tileMap.ZIndex
            };

            foreach (var pos in tileMap.GetUsedCells(layer0))
            {
                var uvs = tileMap.GetCellAtlasCoords(layer0, pos);

                var chunkX = (int)Mathf.Floor(pos.X / World.ChunkSize);
                var chunkY = (int)Mathf.Floor(pos.Y / World.ChunkSize);

                //GD.Print($"({chunkX}, {chunkY})");

                tileLayer.Data[new Vector2I(chunkX, chunkY)][pos] = uvs;
            }

            TileLayers.Add(tileLayer);
        }
    }
}

I know for sure that the pos and uvs are 100% correct. But I am not sure about chunkX, chunkY. I'm not sure how to test if this code works or not. I tried to printing the data to console and the numbers felt off.
The data is stored in a list containing these classes.
public class TileLayerPredefined
{
    public Dictionary<Vector2I, Dictionary<Vector2I, Vector2I>> Data { get; } = new();
    public Texture2D Image { get; set; }
    public int ZIndex { get; set; }
}

I'm not a fan of the Dictionary<Vector2I, Dictionary<Vector2I, Vector2I>>. Because for one how do you define the inner dictionary whenever you add a new element to the outer dictionary, you would need a fancy custom function to handle that. And it looks really confusing at first glance unless you see how it's being used in DefinedChunk.cs. I thought of doing something like Dictionary<Chunk, ...> and putting Vector2I Position property in Chunk but that seems to be even more confusing. I'm not sure.
In World.cs this is how the data is extracted from the PackedScene.
var prefab = GD.Load<PackedScene>("res://Scenes/Prefabs/test.tscn");
var definedChunk = prefab.Instantiate<DefinedChunk>();
definedChunk.Init();

var tileLayers = definedChunk.TileLayers;
// do something with tileLayers...

definedChunk.QueueFree();

Currently I'm not doing anything with this data in commit b09a7c28474154a6ae3b63e802ff298bcad3d526 but if you want to see how this data is used then look at the previous commit 61e6d5f8a50c782258e69975c6bfcd01e9ca83e4

Someone was seeing black lines rendered on their screen when they moved around the meshes but they did not see them when they moved around Godot.TileMaps. So because of this, and not to mention Godot is always continuing to improve their systems I say we should move back to Godots tilemaps. Doing so would also make the codebase much less complex.

Someone was seeing black lines rendered on their screen when they moved around the meshes but they did not see them when they moved around Godot.TileMaps. So because of this, and not to mention Godot is always continuing to improve their systems I say we should move back to Godots tilemaps. Doing so would also make the codebase much less complex.

I'll validate it tonight

Well either way, most likely going to switch over to TileMaps. Even in the Godot release that just came out they worked on improving the TileMaps.


the type java.io.objectinputstream cannot be resolved. it is indirectly referenced from required .class files

Two condition is there where this kind of error will show
1> If there is multiple version of Jdk is loaded in your System.
Solution : Go to control panel>programs & Features: Delete the old version of java and jdk both. keep only latest version of java and jdk. check both java and jdk version is same. Restart your System.
2> The JRE system library is not set properly.
Solution : Go to project>Properties>java build path>libraries : Remove the "JRE System Library". then click on add library select JRE system library the hit next and select work-space default JRE and click on finish.
Then go to project option and click on clean. clean the selected project. it will re build the project.
May be your red alert of error will be eliminated. otherwise follow step 1.

Hi there @iTouhid
thanks for the tip.
This kind of documentation would be easier to find in the forum.
I will close the issue now, as there's nothing to fix code-wise. Thanks again for sharing the info with all!


Markdown underscores prevent word highlighting

VS Code Version: 1.54.3
OS Version: Windows_NT x64 10.0.18363

Steps to Reproduce:

Open an editor with the Markdown Language Mode
Enter the following:

When you click on _this_ word
this will highlight
but _this_ will not

Click on the first instance of the word "this"
The second instance of "this" is highlighted, but the first and third are not
If you remove all the underscores, all three instances will highlight as expected
The same applies for double underscores i.e. bold text

Does this issue occur when all extensions are disabled?: Yes

Edit by @hediet

Duplicate of #86332


Added a "Welcome Page" for new Symfony apps

Problem
When you create a new Symfony app (symfony new my_project) and follow the installer instructions, when browsing the application for the first time, you'll get a 404 error:

Solution
In this PR we add a new simple welcome page to avoid that error. This page is designed for newcomers, so we'll guide them exactly to where they should go: to the doc explaining how to create their first page with Symfony:

If the system doesn't meet some technical requirement, we display instead the following "welcome page":

I don't think that writing the whole logic of the welcome page directly in the DefaultController is a good idea... Isn't it possible to add this behavior in another controller from the framework and do a simple forward?
We removed the entire AcmeDemoBundle a little because of the fact that installing a new Symfony app implied removing this bundle manually, so adding code again that would have to be removed by the devs seems quite a "rewind back"...?

@Pierstoval The logic is just a couple of lines of code - that's quite easy to remove.
:+1:
@javiereguiluz is already aware of this, but we'll need a docs PR when this is merged - it requires some screenshots, so there's no use doing it before a merge.

I've done the suggested changes.
Given that the current situation is dreadful (the first thing you see about Symfony is an error page) I ask you to please make a decision about this PR as quickly as possible. Thanks!

:+1:

Great improvement!
:+1:

:+1:

:+1:

:+1:

:+1:

This is a simple but very effective improvement in my opinion. Great idea @javiereguiluz

I think we're trying to mix two different concepts here:

providing a skeleton allowing developers to start writing their application right away
checking if the environment is correctly set up

When I use the standard edition, I don't directly open a page in the browser: I first start writing my app and then I'll check it later.
AcmeDemoBundle was removed because its purpose was to showcase the code of a Symfony application, and having it in the standard edition just slowed down developers who actually want to just start coding.
On the other hand, I do think we're missing a good tool to check if the environment is set up correctly. But I'd rather see it as a standalone script you could run everywhere.

For people using the Symfony Installer, all technical requirements are checked during the installation and you can see the list of things to fix.
For people still using Composer to install Symfony, they don't get the nice requirements checker of the installer, so it's nice to see the welcome page reminding them about these errors.
For Symfony experts, the new welcome page is just a 3 lines controller and 1 Twig template. They will clean everything very easily.

Contrary to the common denominator I am :-1: because this creates confusion, maybe even documented confusion. I would have initially thought that a default route on / is more than enough.

@cordoval I don't understand your comment :confused: This PR is precisely to provide a default route to /, which currently is missing.

Instead of the demo doing a /examples/page, it could just be /. The demo in the first place missed the point completely.

I have a bit the same feeling as @cordoval and @gnugat. I would love to keep these things simple, as it now contains quite a bit of very confusing things (e.g. require_once in the controller, data urls, lots of logic).
What about removing the requirement check and just link to /web/check.php?

My feeling is broader actually, I remember those days in which symfony was simple :blush: and that we were happy escaping the magic of sf14 and give freedom to users. I know it is a hard critic, I did one project in sf14 for an old client recently and it felt to me simpler than working with symfony2. That feeling sank in me heavily.

I have the feeling that your comments completely not related to this PR, @cordoval. Can you maybe create a new issue for your thoughts on this (as it can lead to interesting results, when thinking about what can be made easier?) in the symfony repository and avoid the noice here? Thanks! :smiley:

@WouterJ I like your last proposal. I've simplified everything in 3196523. Thanks.

@cordoval I don't understand why things are "more complicated" with this PR, even if I'm :-1: for the way it was implemented.
For the rest, I still think that, even if its "only 3 lines of code and a template", it's still much more than "one single line of code" for me...

:+1: for the current state and merging this one quickly

@javiereguiluz Can you update the screenshot in the description to avoid comments about the previous version?

Done.

:+1:

:+1:

It's not magical or anything (like that it's part of the FrameworkBundle defining a default route), its a sensible default with a single page (not a complete bundle). And you are going to change (rather then delete - aka more work) these files anyway, so :+1: for me.
@cordoval

My feeling is broader actually, I remember those days in which symfony was simple :blush: and that we were happy escaping the magic of sf14 and give freedom to users. I know it is a hard critic, I did one project in sf14 for an old client recently and it felt to me simpler than working with symfony2. That feeling sank in me heavily.

Never used Symfony 1.4 :) so can't really tell, what is simple is not automatically easy.
I understand your point, simple implies (simplistic or minimalistic) while easy describes (easy to use and change). I agree on the 'its starts directly from the box' vs 'clean from the box', that it's better (simpler) to get started directly without having to remove allot of demo code. But we also want to keep the experience to be easy and pleasant for newcomers.

@javiereguiluz
For people using the Symfony Installer, all technical requirements are checked during the installation and you can see the list of things to fix.
For people still using Composer to install Symfony, they don't get the nice requirements checker of the installer, so it's nice to see the welcome page reminding them about these errors.
For Symfony experts, the new welcome page is just a 3 lines controller and 1 Twig template. They will clean everything very easily.

I wouldn't use the installer nor composer bootstrap when creating a new server for an existing sf app. I'm actually longing for a standalone script that could be used anywhere, but that's another topic, sorry for bringing it here.
Now back to the actual PR: I don't get the point of having a default page when all I want is an empty skeleton.

@gnugat I helped a user on Twitter just last week - they got the 404 page and thought that tons of things must be broken with their setup because they got an error page when first loading things up. That's the point.

@weaverryan in the case of developers trying out Symfony for the first time, doesn't it make sense to provide them a different application (let's say the AcmeDemo show case application)? To me it sounds more like a lack of explanation / choice on the download page.

Guys, we are trying to help the newcomers, if you already know Symfony, will know that you need to delete 3 lines of code and one twig template, and that won't take much time even if you have to do it multiple times.

@gnugat It depends of what kind of "newcomer" you are. In my case, when I want to discover new frameworks/languages, I won't look at the code at first. I'll create an app. So in the case of Symfony, if I had to discover it today, I'd create an app and start to code right now by following the docs/books.
Even if the Symfony Demo app is great in many points, it depends on each person, and IMO is more for presentations and learnings.
And many other developers will give you different answers. That's why providing a very small working skeleton is absolutely important.

Thank you @javiereguiluz.

Good


Changelog for 0.13.0 - UI

Changes from the UI changelog added

@philipnrmn I rebased that stale branch from Marcus. Can you please review the changelog? Especially if all last changes are reflected. Thanks.

LGTM


Add option to use DisplayScript variables when using DisplayProperties

DisplayScript variables can provide useful information, but they necessitate the use of DisplayScript.
The goal is to add a way to use them with DisplayProperties.
They should be specified as if they were a property, but with some suffix or prefix that is not allowed in property names (perhaps colon or hash?).
Another issue is the format in which they should be displayed. Should they use default string representation? Some dynamically created one (if so, should the dynamic representation be the default one in DisplayScript as well?)
Perhaps it would be possible for the user to specify format string after the property name (E.g. -Properties "#CurrentIteration#d5")

DisplayProperties will be soon removed. See #20


Error redirection

Only redirect users to error redirect if all errors have a redirect value. If there are other validation errors, let the user correct these first.

Does this leave a danger that some slightly odd looking error messages will be displayed for the fields that trigger redirects, but haven't redirected?

Error messages aren't displayed for field errors with redirects, but I don't know why.

https://github.com/UKHomeOffice/passports-form-wizard/blob/master/lib/controller.js#L27-L29

And having said that, I endorse this PR.

If you wanted to merge #27 then I can publish just the once.


UX improvement - improve user readability by pausing animation (auto scrolling) and allow scrollability

The addressed issue
The original implementation of the citation display included an auto-scrolling animation that impacted user readability, making it difficult for users to read the citation text at their own pace. Additionally, there was no scrollbar to provide users with manual scrolling capability, which further reduced usability.
What you have reengineered
I modified the CitationColumn component to remove the auto-scrolling animation and replaced it with a manual scrolling mechanism. I added a styled scrollbar to enhance readability and allow users to scroll through citations at their convenience. The scroll bar includes a thin design with custom colors to improve aesthetics and user experience. Additionally, I installed a new library, tailwind-scrollbar, to facilitate enhanced scrollbar customization.
Reengineering strategy or approach used
I applied a reengineering strategy aimed at improving user experience by:

Removing the CSS animation responsible for the auto-scrolling (animate-marquee).
Adding an overflow-y-auto style to enable vertical scrolling.
Installing the tailwind-scrollbar library to enable enhanced styling of the scrollbar. The scrollbar was customized using utilities like scrollbar-thin, scrollbar-thumb-gray-200, and scrollbar-track-gray-100 for a modern and visually appealing appearance.
Removed unused React hooks, such as useRef and useState, to improve code quality and reduce unnecessary overhead.
Ensured all changes were backward compatible without affecting the existing layout or data.

Impact of changes
The changes made improve user readability and user experience significantly. Users can now control the scrolling of citations, allowing them to read and interact with the content at their own pace. The addition of a customized scrollbar also provides better navigation and a more polished visual design, ultimately enhancing the accessibility and usability of the citation section. Removing unnecessary code also contributes to improved maintainability and performance of the application.
Before
Auto-scrolling animation impacted readability, making it difficult for users to read the citation text at their own pace.

After
Auto-scrolling animation is removed and replaced it with a manual scrolling mechanism.

Tan Zi Yang (U2102745)

okay


Streamlit Hal9 login component

Development

Go to the directorycd python/hal9/login

Rewrite __init__.py setting the _RELEASE variable as false. (NOTE: This variable must be True when releasing the package. This variable switches the source of the frontend code between a dev server for the development and built static files for the production release)

 # the component, and True when we're ready to package and distribute it.
 # (This is, of course, optional - there are innumerable ways to manage your
 # release process.)
-_RELEASE = True
+_RELEASE = False

 if not _RELEASE:
     _component_func = components.declare_component(

In one shell, run the following to launch the frontend dev server.

cd frontend/
yarn install  # This is only needed for the first time.
yarn start

In another shell, run the following to launch the Streamlit app for the development.

streamlit run login/__init__.py

Production build

Move to python/hal9/login/frontend and run yarn build, to build the frontend app as static files.
Ensure that the variable _RELEASE in python/hal9/login/__init__.py is set as True.

Now hal9.login should work.

Thank you @whitphx! Looks good -- However, I don't understand the RELAESE flag, is this to prevent the GitHub action from releasign the component to PyPi? Is the RELEASE flag a standard practice in other Python projects? What would happen if we remove the RELEASE during say development?

@javierluraschi

is this to prevent the GitHub action from releasign the component to PyPi?

No.
It doesn't affect the release flow.
Only that the package will not work if _RELEASE is set as False because in that case it will load the frontend code from the development server (localhost:3001) instead of the built static frontend assets (the ./build directory).

Is the RELEASE flag a standard practice in other Python projects?

It's a standard practice for Streamlit components.
The official template uses this design (https://github.com/streamlit/component-template/blob/master/template/my_component/init.py#L4-L8)
and the official doc also refers to it (docs.streamlit.io/library/components/publish#prepare-your-component).

What would happen if we remove the RELEASE during say development?

The main usage of this flag is here:
https://github.com/hal9ai/hal9/pull/394/files#diff-2dcb88005209e386b445a681e11c2c1d2b4da16df640f8a0051d59e2cc889fcfR5-R9
During the development, as I have written above, we usually use the frontend dev server for the frontend React app and make the Python part to load it (see the if-clause if not _RELEASE:). Instead, for the packaged component, we build the React app as a static file bundle and make the Python code to load it (see the else block).
If we remove the flag, this mechanism becomes unavailable.

@whitphx great, makes sense! Thank you for the detailed explanation. Merging!


Overflow tests failing in Release mode

The tests negative_pos_overflow and negative_neg_overflow are failing in release mode, while passing otherwise.
$ cargo test -r
[...]
---- negative_pos_overflow stdout ----
note: test did not panic as expected
---- negative_neg_overflow stdout ----
note: test did not panic as expected

failures:
    negative_neg_overflow
    negative_pos_overflow

test result: FAILED. 13 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--test test`

$ cargo test
[...]
test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.18s

Version 0.6, commit 1f8620e
Toolchains tried:

nightly-x86_64-unknown-linux-gnu, rustc 1.79.0-nightly (a07f3eb43 2024-04-11)
stable-x86_64-unknown-linux-gnu, rustc 1.77.2 (25ef9e3d8 2024-04-09)

Interesting, I didn't catch that. Could be because debug_assert is disabled.

8311480213d970b45c3900a03f61e1278f2b0529: Disables these tests if we have no debug_asserts. The expected behavior is that all bits exceeding the field size are cut off.