New font format spec

This issue is to stabilize new font format at binary level. It accommodates features, discussed in #990.
Comments and suggestions welcome.

LVGL Fonts format
Based on https://docs.microsoft.com/en-us/typography/opentype/spec/,
but simplified for bitmap fonts:

No separate global header, everything in 'head' table
(?) advanceWidth placed in 'glyf' table
Total glyphs count limited to 65536 (char codes are not limited, up to 0x10FFF supported)

Table: 'head' (font header)
Initial Reference
Global values.

Size (bytes)
Description

2
Record size (for quick skip)

4
'head' (table marker)

1
Number of additional tables

2
Height (px)

2
Ascent (baseline shift from top)

2
BBoxMax X

2
BBoxMax Y

2
BBoxMax Width

2
BBoxMax Height

1
indexToLocFormat in loca table (0 - Offset16, 1 - Offset32)

1
glyphIdFormat (0 - 1 byte, 1 - 2 bytes)

1
kernFormat (0 - 1 byte FP4.4, 1 - 2 bytes FP12.4)

1
Glyph BBox x/y/w/h bits length

1
Glyph advanceWidth bits length

1
Compression alg ID (0 - raw bits, other - TBD)

BBoxMax - BBox of intersection of all glyphs in font. May be useful to allocate
memory for glyph data unpack.
Table: 'cmap'
Initial Reference
Map code points to internal IDs. Consists of optimized "subtables" for compact
data store.
Differs from original by list of fixed subtable headers for quick lookup.
Subtable formats implemented only partially.

Size (bytes)
Description

2
Record size (for quick skip)

4
'head' (table marker)

2
Subtables count

15
Subtable 1 header

15
Subtable 2 header

...
...

?
Subtable 1 data

?
Subtable 2 data

...
...

All subtables are non interserting ranges, headers and content
are ordered by charcodes for fast scan or binary search.
Subtable header

Size (bytes)
Description

4
Min charCode

4
Max charCode

1
Format type

2
Entries count

4
Data offset

Subtable Format 0 data
Initial Reference
Array[uint8], continious, delta-coded. Ideal for ASCII/Latin 1-byte characters.

Index = charCode - (Min charCode)
Map to 1-byte Glyph ID.

Note, "missed" chars are mapped to 0
Subtable Format 6 data
Initial Reference
Array[uint16], continious, delta-coded. Ok for european languages.
The same as Format 0, but supports ids up to 65535. Single subtable is limited to
65536 continuous chars range. More big ranges should be splitted to multiple ones.
Note, "missed" chars are mapped to 0
Spatial format: TBD
Probably, not needed at all, because things can be expressed via list of
continuous subtables. Need to discuss.
Table: 'loca'
Initial Reference
Data offsets in 'glyf' table for each glyph id. Can be Offset16 or Offset32.
Type is defined in head table.

Size (bytes)
Description

4
Record size (for quick skip)

4
'loca' (table marker)

2
Entries count

2/4
id1 offset

2/4
id2 offset

...
...

Table: 'glyf'
Initial Reference
Contains glyph bitmap data. Data offsets for each id defined in loca table.

Size (bytes)
Description

4
Record size (for quick skip)

4
'glyf' (table marker)

??
Glyph id1 data

??
Glyph id2 data

...
...

Note, Glyph ID 0 is reserved for "undefined". It's recommeded set it to
0xFFFE char image.
Glyph data
Stream of bits.
Note, bounding box is NOT related to typographic area (height * advanceWidth),
and can be shifted anyhow. Real image can overflow typographic space.

Size (bits)
Description

NN
advanceWidth (length in font header)

NN
BBox X (length in font header)

NN
BBox Y (see length in font header

NN
BBox Width (see length in font header)

NN
BBox Height (see length in font header)

??
Compressed bitmap

Table 'kern'
Initial Reference
Kerning info (optional). List of records [ id_left, id_right, kerning_value ]

id - 1 or 2 bytes (glyph id from cmap table)
kerning value - FP12.4 or FP4.4 fixed point value (1 or 2 bytes)

Size of glyph id & kern value defined in head table.

Size (bytes)
Description

4
Record size (for quick skip)

4
'glyf' (table marker)

4
Entries count

3-6
Kerning record 1

3-6
Kerning record 2

...
...

All records MUST be ordered by (id_left, id_right) to allow fast binary search.
TBD

BBox dimensions length is usually 4-5 bits. Should we use separate dimensions
for overflowed value (those are 1-2 bits larger)? Need to measure difference.
Format version info?

Initial idea of keeping chunk headers into font head was possibility of binary search. But this does not seems very useful

because number of chunks will be small
cache can be implemented in runtime

I tend move chunk headers back into chunks, to have this info more "condensed"

Moved chunk heads to chunk bodies.
https://github.com/littlevgl/lv_font_conv/blob/font_spec/font_spec.md - here is my "sandbox" of updates, is anyone interested.

After investigating kerning info, i found data to become too complicated. Tend to pack it more close to OpenType tables (without chains).

Glyph data should have internal continuous enumeration (not pinned directly to char codes)
Features of "continuous"/"sparse" compact store is related to charcodes only, not to glyph bitmaps. In this case it has equivalent in OpenType spec (subtables).

Pros:

More friendly to next extensions
More easy to understand/verify
Reduce "inventing new standard" attempt => less design errors
(?) able to deduplicate idedtic glyphs from different scriptings (unicode blocks)

Cons

May need some state store in RAM (pointers to active tables and so on) for effective work

Updated first message with new format, based on OpenType principles.
History: https://github.com/littlevgl/lv_font_conv/commits/font_spec
@kisvegabor, @embeddedt, @beibean, I think this format can be useable. Need to discuss, check missed features and stabilize.

@puzrin This format will be used internally, and writes can convert it to the required format, right?

IMHO it would be nice to use it in LVGL directly.
Anyway, when we design complex data, we should think in "bytes" domain, not in specific language. That's more clear, more easy to apply external patterns (from OpenType in our case), to quick-check features availability (like binary search) and so on. I've completely rewritten spec 3 times, this would not be so easy if it was in C.
Probably, this data can be expressed in C, but for me this would be a waste of time. If someone provide me correct example of such translation - i probably could try to create such writer. But i would strongly recommend to start with redesign of public API (font expression in C is internal thing).
We are still in the middle of of new fonts data/API design. It's too early to speak about C writer. I tried to explain all process here https://github.com/littlevgl/lv_font_conv/issues/7#issuecomment-480119718

Under new API i mean something like:

font->render(string)
font->getGlyphId(charCode)
font->getBitmapInfo(id)
font->getKerning(left_id, right_id)

That's only an example, only to demonstrate that existing API should be reworked, to reflect new data/features. Don't consider as real methods.

It sounds reasonable to update the font API this way, however, as I stated in other posts it can be part of an n other release.

@kisvegabor i don't agree. It does not worth to plan jump over chasm with two jumps :).  API rework is MUCH more simple, than change data twice.
To be constructive, i suggest to create new issue about font API rework, collect requirements and design function signatures. This does not involve coding, allows verify almost everything and do estimates about cost. If we find cost not acceptable - we can start search plan B. But new format is very modular and should not be difficult to switch.

For example: i you find decompressor implementation difficut, we can support "raw bits" in 6.0 release, and add compressor in 6.1. This will not affect existing spec and API.

Updated TBD section with questions. Need to discuss.

To be constructive, i suggest to create new issue about font API rework, collect requirements and design function signatures. This does not involve coding, allows verify almost everything and do estimates about cost. If we find cost not acceptable - we can start search plan B. But new format is very modular and should not be difficult to switch.

Sounds good. Please open a new issue for the new font API and we will see if it's possible to add it in v6.0

In light of the progress in the API topic, we need to clarify what is the exact purpose of this data representation format.
Anyway, to make some progress here I answered the general questions of the TBD section:

Coordinate system. Where to place (0, 0) ? Baseline? Ascent? Descent?

I vote for the ascent. It's the most natural while drawing. We should have "baseline" attribute too (e.g. baseline == 12) to enable positioning the label with its baseline.

Should we keep advanceWidth in separate table? (need measure size difference)
current location seems ok for quick lookup.

I see no disadvantage of storing advanceWidth in different tables. When people need a monospace font they usually have a resource constraint environment. So saving memory, in this case, is important.

Need samples for CJK subsets, to understand need of spatial subtables (still can
use lot of holed Subtable Format 6 with binary search for fast lookup).
Do we need something special for proper CJK render?

As you already know currently we have continuous and sparse fonts. Sparse is tested with CJK by a lot of people and they had no problem with that. So I think we don't need anything else than supporting sparse fonts.

Should we care about data align? What is the size cost of it?

Yes, sections/tables should be aligned to 4 bytes boundary.

In light of the progress in the API topic, we need to clarify what is the exact purpose of this data representation format.

That's a part of "standard" design process:
[ collect use cases ] => [ design data flow ] => [ design api/code ]

This data reflects required features (https://github.com/littlevgl/lvgl/issues/990).
This format helps to verify logical correctness.
It's used to design writer (font convertor) & reader (lvgl api).

I vote for the ascent. It's the most natural while drawing. We should have "baseline" attribute too (e.g. baseline == 12) to enable positioning the label with its baseline.

Just to clarify, you suggest set (0, 0) to upper left corner? And glyph will be drawn "right and down" (except case with negative shifts)?

I see no disadvantage of storing advanceWidth in different tables.

I'd say, i could not find reason to create additional table. OpenType's one is for more complicated features, not used in our case.

When people need a monospace font they usually have a resource constraint environment. So saving memory, in this case, is important.

That's not related to storage location. Just set number of bits in advanceWidth to 0 + add default value field to font header.

As you already know currently we have continuous and sparse fonts. Sparse is tested with CJK by a lot of people and they had no problem with that. So I think we don't need anything else than supporting sparse fonts.

Can i see examples from real world? I need to understand subsets of used charcodes
That's required to understand do we need additional subtable format, or we can use multiple of existing subtables.

Yes, sections/tables should be aligned to 4 bytes boundary.

Ok, i will align everything according to addressed data width
The only question is with glyf table. It would be nice to aligh each "glyph bitstream start" to 4 bytes, but this can add notable overhead. Need to compare losses for real fonts.

That's a part of "standard" design process:
[ collect use cases ] => [ design data flow ] => [ design api/code ]

This data reflects required features (#990).
This format helps to verify logical correctness.
It's used to design writer (font convertor) & reader (lvgl api).

I agree it is useful the verify logical correctness but not sure it's required to specify the exact format (bits, sizes, alignment). However, if you think it will help later, I believe. :)

Just to clarify, you suggest set (0, 0) to upper left corner? And glyph will be drawn "right and down" (except case with negative shifts)?

Yes.
AdvanceWidth table:

That's not related to storage location. Just set number of bits in advanceWidth to 0 + add default value field to font header.

Ok, if it works here. Probably in lv_font_t it really should be a different table but don't mix LittlevGL specific things here.

Can i see examples from real world? I need to understand subsets of used charcodes

I can't link any exact resources. I just saw here that people sent screen shoots with CJK characters to ask something.

That's required to understand do we need additional subtable format, or we can use multiple of existing subtables.

I'm not sure subtables really could work in this case because characters can be really sparse. My experience is CJK symbols, because of mean words, can't be grouped to logical subsets. Have a look at this. The symbols are just divided into 4 equal parts.

I agree it is useful the verify logical correctness but not sure it's required to specify the exact format (bits, sizes, alignment). However, if you think it will help later, I believe. :)

If people can understand something wrong - they will do it :). It's much more cheap to write exact spec, than do multiple code rewrites and try to find difference between JS writer and C reader :).

Ok, if it works here. Probably in lv_font_t it really should be a different table but don't mix LittlevGL specific things here.

If you speak about head table - that's for internal implementations and NOT lv_font_t. I guess, it can partially go to extension of lv_font_t, specific for LVGL font engine.
Note, font spec is not about particular implementation. It's about data to make features possible. head store assorted properties, because those are required.

Can i see examples from real world? I need to understand subsets of used charcodes

I can't link any exact resources. I just saw here that people sent screen shoots with CJK characters to ask something.

That's required to understand do we need additional subtable format, or we can use multiple of existing subtables.

I'm not sure subtables really could work in this case because characters can be really sparse. My experience is CJK symbols, because of mean words, can't be grouped to logical subsets. Have a look at this. The symbols are just divided into 4 equal parts.

Ordered tuples with delta-coded index should be ok:
subtable_format_sparsed[] = {
  { uint16_t (CJK1 - range_start), uint16_t glyph_id1 }
  { uint16_t (CJK2 - range_start), uint16_t glyph_id2 }
  ...
}

4 bytes per entry (every subtable covers up to 65336 wide range).
Ready for binary search.

The only reason why i did not added this yet - there are no direct analogues in OpenType spec, and i can't understand why.
https://docs.microsoft.com/en-us/typography/opentype/spec/cmap there format2 & format4 but those break my brain :).

Refreshed spec according to comments. Key points:

Updated header info (drop bboxMax, leave Y min/max only)
Improve cmap subtables descriptions
Add sparsed subtable format
Aligned everything possible
Rearranded kerning table to simplify aligned access

Diff: https://github.com/littlevgl/lv_font_conv/commit/43c6f315cd61542ba142bf6a1cd84c97b93add58

Ordered tuples with delta-coded index should be ok:

Something like that could work.

There are Format2 & Format4 but those break my brain :).

It really looks complicated. I don't think we need to follow OpenFont so strictly.
Glyph's bitmap alignment:
As they will be stored and used byte-based I don't think alignment is required there. Now it's not aligned and there were no problems with that. A problem could occur if an uint32_t would be read from a not 4 aligned address. But for bytes, it should be fine.

Glyph's bitmap alignment:
As they will be stored and used byte-based I don't think alignment is required there. Now it's not aligned and there were no problems with that. A problem could occur if e.g. an uint32_t would be read from a not 4 aligned address. But for bytes, it should be fine.

Content of glyph data is bit stream. Normal operation usually is:

prefetch some bytes
peak requested number of bits, until new prefetch needed

With aligned data we could prefetch 4 bytes at once. I guess, there should not be big difference, but byte access looks not nice.

The updated spec look good to me. Do we need this issue opened?

Yes, i'd like to keep it open for 1-2 weeks.

Too few feedback in general.
We did not collected feedback from API issue.
Need to decide where to land spec document.

With aligned data we could prefetch 4 bytes at once. I guess, there should not be big difference, but byte access looks not nice.

I see no advantage of accessing it as 32 bit data. You can consider the glyphs data as an uint8_t array:
const uint8_t * p = glyph_bitmap[glyph_start];
p[x] ... ;

Yes, i'd like to keep it open for 1-2 weeks.

Ok

See updated TBD. Should we expose recommended glyph buffer size into header? This looks too "low-level-ish".

Rigth values is MAX(all_glyphs)
Each glyph's value is wordAlign(bitmap_width) * bitmap_height (bitmap_width depends on bpp)

This will require to scan loca / glyf tables.
I can't explain why i don't like to hardcode allocator hint into font.

I think storing this information is useful and I see no problem with that. It's better if do it instead of letting it to the user.

Updated spec. Found some minor issues after started with bin writer.

missed bpp info :)
BBox X/Y are signed, BBox W/H are unsigned. Splited bits length to separate filelds.
advanceWidth MAY be in fixed point format (if kerning info used, last 4 bits should be fractional). Added format field + appropriate notes. For "ugly" OLED fonts this may be integer.

Diff

https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align - this is very useful article to understand font align inside of line.
I'm not sure we need features like font mixtures and different aligns, but still worth to read.

I'll check it!

Quick summary about "proper" default font positioning inside line
$ env DEBUG=* ./lv_font_conv.js --font ./node_modules/roboto-fontface/fonts/roboto/Roboto-Regular.woff -r 0x20-0x7f --bpp 3 --size 24 --format dump -o 1111

24px dump will give this params:
{
  "ascent": 22,
  "descent": -6,
  "size": 24,
}

I will use terms from article.

EM Box (1em) is 24px.
Content box [ascent + descent] is 28px (bigger). Note, some glyphs still can be larger.

Normal line height is usually 1.2-1.5em => 29-36px. By default, EM Box (and Content Area) are centered inside of line.
Content Area (28 height) offset from line top will be 0.5-3.5px.
Currently we agreed to count glyph bitmap (x, y) offset relative to content area (top, left).

I read the article. Just a few things to be sure we understand things in the same way:

"size": 24 doesn't really matter while drawing or calculating things, right?
No character will be larger than 28 px? So any text will fit into a 28 px heigh box?
"ascent": 22 means the baseline is 22 px down from the top of the 28 px line box?
Now style->text.line_space means the gap between two lines.
It should be updated to style->text.line_height.
The default value should be e.g. font->size * 1.2.

"size": 24 doesn't really matter while drawing or calculating things, right?

Yes. It's intendend to implement design with ease. So, when designer says "This screenshot uses Roboto Regular 16px" - you will get the same look in LVGL, without need to scale, shift and so on.

No character will be larger than 28 px? So any text will fit into a 28 px heigh box?

There are a lot of confusion about this. If you open FontForge, there THREE types of ascent/descent.

General asc/desc - used to draw top/bottom lines when you open glyph
Win asc/desc - (?) for Windows, includes space to line top, descent is positive (inverse)
HHead asc/desc - (?) for Mac, similar to Win asc/desc, negative descent. May be different, but not significantly.

We need some time to understand, how to properly scale/center font.

"ascent": 22 means the baseline is 22 px down from the top of the 28 px line box?

To be more precise - fonts have no top. They have baseline and lot of metrics, counted from baseline.

Now style->text.line_space means the gap between two lines.
It should be updated to style->text.line_height.
The default value should be e.g. font->size * 1.2

Yes, it's much better to operate with line-height
Usually, line-height should be set according with used font-size, to get "round" result. That also depends on design.

There are a lot of confusion about this. If you open FontForge, there THREE types of ascent/descent.

To be more precise - fonts have no top. They have baseline and lot of metrics, counted from baseline.

> {
>   "ascent": 22,
>   "descent": -6,
>   "size": 24,
> }

It was for the whole font, not for a single glyph, wasn't it? If yes, based on the article, it should mean the
content area = 22 - (-6) .

It was for the whole font, not for a single glyph, wasn't it? If yes, based on the article, it should mean the
content area = 22 - (-6) .

Yes.
But we expected this to be "general ascent/descent", and js libraries seems to return HHead asc/desc. Difference is significant:

General asc: 1536
General desc: 512
EM: 2048
OS/2 Typo Ascent: 1536
OS/2 Typo Descent: -512
OS/2 Typo Line Gap: 102
OS/2 Win Ascent: 1946
OS/2 Win Descent: 512
OS/2 HHead Ascent: 1900
OS/2 HHead Descent: -500
OS/2 HHead Line Gap: 0

We need couple of days to understand what hell happens. And which metrics use to scale down.

Collapsed all previous commits to hide garbage.
Also, did some changes to reflect latest thought and ideas:

Added "typographic" ascent/descent/linegap
Changed subtable headers format:

use "range" instead of "last code", to save 2 bytes
use saved bytes to store Glyph ID offset. That will allow use Format 0 "everywhere", and mark Format 6 as "reserved" (tend to drop, but not ready to do it now)
Updated fields order to have longest (4 bytes) first.

Diff
Why "typoXX" metrics
Current ascent/descent reflect MAX possible top/bottom + include line gap in ascent. So, align inside line may change, if you add letters like Ȃ and others. Typographic ascent is more close to "upper line of capital letters" and not depends on artefacts.
I don't mean we must use typoXX metrics, but prefer to reserve 6 bytes of flash and avoid format change if we need experimenting.
Also, i don't know what to do if we merge 2 fonts with different metrics. Now we just scale down each font according to their EM Units and use metrics from first one. Should be enough for us.
To count intersection with framebuffer region - use minY and maxY - those are always recalculated for all glyphs.
Convertor script is not yet updated, but will reflect changes soon.

Updated convertor. Now seems ok.
Since different ascents can be used, it seems more reasonable to define bitmap's bbox y offset from baseline - it's more "stable" and more "common" (as in vector fonts).
Any principal objections?

Updated convertor, added tests and fixed some bugs. Now binary outpot should be correct.
Current coordinates of glyph's bitmap bounding box are:

(x, y) defines (bottom, left) corner.
BBox (0, 0, ...) is at (left side, baseline)
Axis directions are (right, up)

Bitmap's content is from (top, left) to (right, down), as usual.

Since different ascents can be used, it seems more reasonable to define bitmap's bbox y offset from baseline - it's more "stable" and more "common" (as in vector fonts).

I agree.

(x, y) defines (bottom, left) corner.

Why the bottom corner? Using the right - down axis direction is more common. Is there any reason to do it differently in this case?

Why the bottom corner? Using the right - down axis direction is more common. Is there any reason to do it differently in this case?

2 reasons:

More close to OpenType fonts (and font editors). I don't like to reinvent wheels and new standards without need.
Not depend on prefered ascent type (you can switch from "typography ascent" to "hhead ascent", without need to update coordinates).

Image, to avoid confusion:

However, it's the same for letters with "special lower part", right? For example Ų or Ç.

However, it's the same for letters with "special lower part", right? For example Ų or Ç.

y = 0 is always at baseline. g, j, Ų, Ç will have negative y

I mean it seems to me the problem still persists just now with "HHead Descent" and "Typo Descent".

I'd say, this coordinates may seems strange to one who did not worked with fonts. But that's not fatal problem and not technical difficulty.

Usually, you already have layout and know exact linebox where to fit line of text.
Then you can use typoAscent + typoDescent to estimate "visual height" of text, align this inside line box and count baseline position.

I need to know the content-area to set the label's size accordingly. It should include all accents because the letters can be drawn only on the label's area. I can modify this line's height with the line_height from the style to get the line_box.
In summary, I need to know 3 things:

the absolute maximum height of a line (virtual_area ?). Probably HHead ascent + HHead descent
the baseline relative to the maximum height
Glyph's BBox y offset. It can represent the top or bottom edge of the box, doesn't really matter.

Hm... i don't see question in your post. What is the problem with?

Oh, sorry. :) The question is: does it "work" this way? Or in other words: Is it possible to and do you agree to create the listed data for the built-in font format?

Is it possible to and do you agree to create the listed data for the built-in font format?

Not sure i understand you again :). See first post, font header table section. All this data seems already exist, and generated in --format bin.
https://github.com/littlevgl/lv_font_conv/blob/50c8664844085b0e7bd4ce585f6a269ee23a6a90/lib/font/table_head.js#L53-L62
Dit i missed something?

Not sure i understand you again :). See first post, font header table section. All this data seems already exist, and generated in --format bin.

I wanted to be 100% sure that we will have an "ultimate line-height" because it's the most important from LittelvGL's point of view. But then it seems fine. Thank you.
Next week I'll make some experiments with kerning too. When it's ready, I'll be able to provide a template file for LittlevGL built-in fonts. You mentioned that you are not interested in creating an lvgl6 text writer. Is this still true?

You mentioned that you are not interested in creating an lvgl6 text writer. Is this still true?

The most boring part is inventing good text format. I'm not interested in spending time for this. But if someone provides ready format, i could try to make JS part, if that helps.
Under "ready format" i mean "no magical numbers" (except array sizes). For example, i have no ideas how to define data offsets in glyf & cmap tables.

It would b great if you created the JS part. I will make the ready text format. Is it good if we will have a small example font? Like (this)[https://github.com/littlevgl/lvgl/blob/font/src/lv_fonts/lv_font_dejavu_20.c].

Is it good if we will have a small example font?

Yes. In case of "text format", example font with couple of dummy glyphs should be enougth.

Awesome!

Need to decide where to land font format spec:

lvgl repo
lv_font_conv repo

lv_font_conv would be more logical if script will be used independent, with other libs (to keep project consistent). In other cases lvgl may be preferable.
I'll be ok with any choice, if i have write access to spec next 1-2 months, for polish.

lv_font_conv would be more logical if script will be used independent, with other libs (to keep project consistent). In other cases lvgl may be preferable.

I agree. Please upload it there.

Landed to https://github.com/littlevgl/lv_font_conv/blob/master/doc/font_spec.md
Seems all done, but i'd suggest keep issue open until API finished. To discuss data change & clarification requests (i hope this will not happen but can not guarantee 100%).

Kerning table size
Usually ~50% of glyphs has kerning. Size of kerning table in Format 0 has quadratic dependency on glyphs count.

As far as i understood, real kernig is defined not for glyphs but for classes (groups of glyphs). For example for AO, AC & AQ chars O,C,Q belongs to the same class.

See Format 2.
Also see Format 3, it seems more easy to understand, and more compact

So, we have to store:

Mapping chars to Left Class ID (893 bytes), ~ 40 classes
Mapping chars to Right Class ID (893 bytes), ~ 40 classes
Table leftClassesCount * rightClassesCount * kern_value_size, ~1600 or 3200 bytes.

Big difference!
Of cause, this may work only if original font uses definition via table. But all modern fonts should have it (because that's more convenient for font authors).
I did not investigated details, may be for ascii Format 0 will be more compact.

Second point is "micro optimization" for kerning value size. 8 bits is not enougth for huge fonts (> 50px). Currently spec switches to 16-bits values.
Alternative may be introduce property kerningMultiplier. Actually, 7-bits  (+sign) resolution is enougth, if used with proper scale. Requires trivial FP multiplication (hardware int mul support should be available in all lvgl targets).
Just an idea.
This also open ability to create "font packs" with different font sizes and shared kerning table. BUT, at first glance, after add Kerning subtable Format 3 support, saving will be not significant.

Next 1-2 weeks will try to invent "table restorer from glyph pairs" algorythm.

Checked cmap subtables for full Roboto dump:
12 subtable(s): 9 "format 0", 3 "sparse"
That means, in worst case 4 binary search iterations required to find subtable. Nice. Should not affect performance.

https://github.com/littlevgl/lv_font_conv/commit/e4e0a8504d2922379bc5cd1f7c4705cbb613f493
Updated spec & code to use kerningScale FP12.4. That will simplify upcoming kerning subformats changes.

Also pushed to temporary kern branch calculation of glyph "classes" (grouping) stat, required for subtables format2/format3 support.
0x20-0x7f:
$ env DEBUG=* ./lv_font_conv.js --font ./node_modules/roboto-fontface/fonts/roboto/Roboto-Regular.woff -r 0x20-0x7F --size 16 --bpp 3 --format bin -o test.bin
  ...
  font.table.glyph table size = 2836 +0ms
  font.table.kern 51 kerned glyphs of 95, 40 max list, 434 total pairs +0ms
  font.table.kern unique right classes: 40 +8ms
  font.table.kern unique left classes: 35 +2ms
  font.table.kern table size = 1316 +0ms
  font font size: 4524 +25ms

0x20-0x10FFFF:
$ env DEBUG=* ./lv_font_conv.js --font ./node_modules/roboto-fontface/fonts/roboto/Roboto-Regular.woff -r 0x20-0x10FFFF --size 16 --bpp 3 --format bin -o test.bin
  ...
  font.table.glyph table size = 32484 +0ms
  font.table.kern 447 kerned glyphs of 893, 413 max list, 52248 total pairs +0ms
  font.table.kern unique right classes: 83 +116ms
  font.table.kern unique left classes: 103 +124ms
  font.table.kern table size = 261252 +1ms
  font font size: 296992 +412ms

In Format 3 kerning will be:

ascii - 96*2 + 40*35 => 1592 bytes
full -> 893*2 + 83*103 => 10335 bytes

Note, for unknown reasons Roboto stores data in 2 subtables (GPOS, pairs + format2). And it's format2 table dimension is ~40*40 (we have twice more). Need some checks what happens, but even preliminary results looks nice.

https://github.com/littlevgl/lv_font_conv/commit/70784b624d4dd965a2f16661ce3ccce2ab0c6532
Upcoming update of Format 3 for kerning table.

I've also seen that usually using classes are used to save memory. It seems more effective but we need to ensure that the converter works with any font. At worst case, it should skip the kern table if it's format is not supported.
Width byte size
I'm not sure 2 bytes are really required. Probably 2 bits for the fractional part would be enough too:

1 bit sign
5 bit integer part
2 bit fractional part

This we will have -31.75 .. 31.75. It should be enough for 100 px fonts too.

It seems more effective but we need to ensure that the converter works with any font.

It will select most optimal format of possible. I don't understand why you decided in can not work with some fonts.

At worst case, it should skip the kern table if it's format is not supported.

Sounds like "magic". Convertor works as it can, and write least possible size. It's user's responsibility to take modern font.

Width byte size
I'm not sure 2 bytes are really required. Probably 2 bits for the fractional part would be enough too:

Are you about width or kerning? Kerning is 0.1 in many cases of 16px font. I don't like to restrict resolution with 2 bits fractional. And i don't like to restrict max possible size with 200px (some chars will have kerning > 31)

Sounds like "magic". Convertor works as it can, and write least possible size. It's user's responsibility to take modern font.

I absolutely don't agree. We need to add as few restrictions as possible. If the user wants to use a font for any reason we need to do our best to make possible the use of that fonts.

Are you about width or kerning? Kerning is 0.1 in many cases of 16px font. I don't like to restrict resolution with 2 bits fractional. And i don't like to restrict max possible size with 200px (some chars will have kerning > 31)

Limiting the font size around 200 px and 0.25 px resolution is reasonable compared to the cost of an extra byte. With proper rounding the error will be <= 0.125 px which is very acceptable.

I absolutely don't agree. We need to add as few restrictions as possible. If the user wants to use a font for any reason we need to do our best to make possible the use of that fonts.

Seems i missed the point of discussion. Initial (source) font  font are correct, and author draw it with appropriate features (with of without kerning, depending). Changing author intents is not good. Convertor keep those features and write file of minimal size. What's wrong?

Limiting the font size around 200 px and 0.25 px resolution is reasonable compared to the cost of an extra byte. With proper rounding the error will be <= 0.125 px which is very acceptable.

IMO, you discuss problem that not exists.
https://github.com/littlevgl/lv_font_conv/commit/e4e0a8504d2922379bc5cd1f7c4705cbb613f493
Current spec has scale property, 8-bit kerning values and no restriction about font size.

@puzrin

And i don't like to restrict max possible size with 200px

As far as I know, LittlevGL is not designed with ultra-high-density screens or extremely large screens in mind. On my computer monitor (~27in with a resolution of 1920x1080) I can only display 4-5 lines of text with a 200px font size. Most embedded systems have much smaller displays. Therefore, I can't see a practical use case where 200px fonts would be required. If, at some point in the future, such display technology becomes mainstream in embedded systems, then an extension of the font specification to allow that would make sense. However, at the moment, I don't the reason to support this for an embedded GUI library designed for constrained environments.

I consider a bad practice to select restricted solutions at data level. If i can juggest more universal solution for the same cost, why should i select one less universal?

On my computer monitor (~27in with a resolution of 1920x1080) I can only display 4-5 lines of text with a 200px font size.

Device can show big single line of rolling text. Just an imaginated example.

I've updated convertor & spec.
Now it tries to build kerning with Subtable Format 3 and Subtable Format 0, then selects least possible. Size of full Roboto dump (16px, 3 bpp) reduced from 250K to 50K.

Initial (source) font font are correct, and author draw it with appropriate features (with of without kerning, depending). Changing author intents is not good. Convertor keep those features and write file of minimal size. What's wrong?

We cannot introduce new restrictions on the user. If, for whatever reason, they wish to use a font in a different way than intended, that's their decision, not ours.

We cannot introduce new restrictions on the user. If, for whatever reason, they wish to use a font in a different way than intended, that's their decision, not ours.

Option to drop kerning data was added 2 weeks ago: https://github.com/littlevgl/lv_font_conv/commit/2a915e09a9fcc3a7f102db171c93aaf7ef81aa8e. And this is convertor's feature, not related to data spec.

Kerning types
What happens if the user tries to convert an "exotic" font which kerning format is not supported? Will he get an error or just a warning saying that "kerning format is unknown so it is skipped".
Kerning format 3
Where are the letters for each class are stored? I.e. how do you know that 'C', O, Q are in the same class?
Max height
We need to decide the requirements first then write spec accordingly.  200 px fonts are enough in our case so 1 byte is required here.

What happens if the user tries to convert an "exotic" font which kerning format is not supported? Will he get an error or just a warning saying that "kerning format is unknown so it is skipped".

We use opentype.js to extract kerning data. I guess, if format not supported it returns 0.

Kerning value
How is it stored in higher resolution in one byte? Send a link please.

You mix terms "scale" and resolution. Resilution stays the same, 8 bits. Scale is stored in header.

https://github.com/littlevgl/lv_font_conv/blob/master/lib/font/font.js#L42
https://github.com/littlevgl/lv_font_conv/blob/master/lib/font/font.js#L105

Kerning format 3
Where are the letters for each class are stored? I.e. how do you know that 'C', O, Q are in the same class?

Glyphs, having exactly the same combinations of kerning have the same class. Convertor scan values and build class lists.
https://github.com/littlevgl/lv_font_conv/blob/master/lib/font/table_kern.js#L111-L125

Note about single kerning value format. Now we have FP4 in 2 places:

kerning values (FP4.4)
kerning scale (FP12.4)

We could store instead:

kerning value as Uint8
Kerning scale as FP8.8

I don't know does it worth to do such thing or not. Technically - no difference, because those must be multiplied anyway.

In light of this comment I close this issue. Let continue in #1057


[bug] Jimmer doesn't honor setAppendOnlyAll() if associated entity contains @Key

If an associated ToMany entity contains @Key setAppendOnlyAll() is ignored and jimmer always tries to select the association.

Try 0.8.117

setMergeMode and setAppendOnly are deleted, there are replaced by setAssociatedModeAll and setAssociatedMode

shortcut function merge is NOT changed.

and new function shortcut function append(Forget one thing, now it is upsert root + insert associated objects, in next version, it will be changed to insert root + insert associated objects)


Wait for created resources to be deleted

This is to avoid issue with hitting an error while a namespace store is being deleted.

Signed-off-by: Vineet Badrinath<EMAIL_ADDRESS>

/test odf-console-e2e-aws

/test odf-console-e2e-aws

/test odf-console-e2e-aws

/approve


HTML

HTML
User Story
As a boot camp student,
I want a Prework Study Guide website,
so that I can review all the information I learned throughout Prework.
Acceptance Criteria
GIVEN a Prework Study Guide website
WHEN I visit the website in my browser
THEN I see four boxes titled HTML, CSS, Git, and JavaScript with associated notes listed

Beauford reset your computer in the middle of this and deleted the original index file so hopefully it's not messed


on using Phantom wallet it doesn't recognize it is is already installed, no solana chain

Describe the bug
on using Phantom wallet it doesn't recognize it is is already installed in a browser, no solana chain
SDK Version
2.1.1
To Reproduce
Steps to reproduce the behavior:

Go to connect button
Click on chain
select phantom wallet
See error it asks to install although other sites see it

Expected behavior
Should see it even if solana chain is not available
Screenshots

Desktop (please complete the following information):

OS: Windows 11
Browser Chrome
Version Wersja 110.0.5481.104 (Oficjalna wersja) (64-bitowa)

I think you forgot to add link to the dapp?

you mean my platform using web3modal? it is cyberwealth.pro/app

after commit on references in wagmi, how long it takes to get minor update into new release? I added Harmony One chain

Just tested your use-case, does phantom already support evm chains? We added it into the modal a while ago, but perhaps they didn't release this version yet.
I am looking at window.ethereum and it seems like phantom is not injecting it, only window.phantom for solana.

I would like to contribute more for web3modal and wagmi :) so will web3modal work with window.solana?

So, if @web3modal/standalone and @walletconnect/sign-client are used together as per this example https://docs.walletconnect.com/2.0/web3modal/standalone/installation then yes, you can already use any chain or combination of them, however only with walletconnect specific functionality.
To manage injected extensions / getting balances etc. we rely on wagmi for eip155 chains (evm chains). We started solib for this purpose for solana, but team is currently busy with protocol v2 updates. We will, however, return back to solana integration soon.
Feel free to play around with solib and see if you can bring it to a state where it supports similar api as @web3modal/ethereum package (https://github.com/WalletConnect/web3modal/tree/V2/chains/ethereum)
But we might need to tweak things in web3modal as well to support proper multichain.
For now I will close this issue, I'm pretty sure phantom's evm support is not rolled out yet (or maybe it is behind some feature flag?) so it won't work at the moment.

Thanks very much ill stick to web3modal and will help if possible, cheers!


Increase logical FPS for simulations and games

Naively simulating physics in a simulation or game is frustrating, because the Euler integration we do causes the system to slowly gain energy over time.  While this can be solved using semi-implicit Euler integration, this is still surprising to students.
We could go a long way toward fixing this problem by adopting a different strategy: in simulation and interaction modes, instead of drawing every frame, we could loop calculating new states as quickly as possible (possibly much faster than 60 fps), and then only draw a frame at the desired (lower) frame rate.
The trade-off (aside from just general wasted computation or battery life) would be that we'd lose a way to show something for exactly one frame.  Right now, a students can flash a color or something for one frame, ensuring that it does get drawn, but for no longer than needed.  It's not clear if that's important or something people will rely on.

Decided against this one.


[type:refactor] log use godkits

With pull requests:

Open your pull request against main
Your pull request should have no more than two commits, if not you should squash them.
You should pass all tests by go test -v ./... at the project root path in local.
It should pass all tests in the available continuous integration systems such as GitHub Actions.
You should add/modify tests to cover your proposed code changes.
If your pull request contains a new feature, please document it on the README.

Codecov Report

Merging #66 (9512026) into main (c227c1e) will increase coverage by 0.30%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##             main      #66      +/-   ##
==========================================
+ Coverage   61.08%   61.38%   +0.30%
==========================================
  Files           8        8
  Lines         203      202       -1
==========================================
  Hits          124      124
+ Misses         64       63       -1
  Partials       15       15

Impacted Files
Coverage Δ

internal/pkg/config/config.go
33.33% <0.00%> (ø)

pkg/entity/data/envcd_data.go
81.81% <0.00%> (ø)

internal/core/exchanger/etcd/etcd.go
48.00% <25.00%> (+0.94%)
:arrow_up:

internal/pkg/config/conn_metadata.go
87.50% <87.50%> (ø)

internal/core/plugin/chain.go
40.00% <100.00%> (ø)

internal/core/plugin/logging/logging.go
67.74% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c227c1e...9512026. Read the comment docs.


[ENHANCEMENT] LLM based reranker support

Is your feature request related to a problem? Please describe.
Have the ability to use a LLM as a reranker in Marqo and allowing for augmented retrieval. Currently this is not supported. This can allow for using the LLM as a reranker ("rank these based on X...") or summarisation and to cite the original work.
Describe the solution you'd like
when searching have the option to add a LLM as a reranker. Initially it should support hosted endpoints for the LLMs.
client.index(index_name).search("why is the sky blue", reranker={"name":'GPT3', 'api_key':###, 'engine':'davinci-003', prompt = "Given the query and the context, summarise and cite the references. QUERY:{}"}
It could allow for a free text prompt or some could be curated for predefined tasks, e.g.
task="summarise"
Describe alternatives you've considered
Additional context
An example here https://github.com/marqo-ai/marqo/tree/mainline/examples/GPT3NewsSummary
this feature would bring the functionality to within Marqo.

very early draft of branch https://github.com/marqo-ai/marqo/compare/mainline...gpt_reranker1.

GPT3 reranking for Marqo
Overview
We can use GPT3 to rerank the results of a Marqo retrieval. We can benefit from the fast retrieval of tensor and lexical search, coupled with LLM reranking models' slower,
but potentially more accurate, reranking ability.
This will also pave the way for alternative text-based model rerankers, and 2nd stage text retrieval processing. For example, text summarisation.
Release note blurb
Marqo-GPT3 integration: GPT3 is now available as a Marqo reranker. Retrieve your documents via tensor search, and re-order them with GPT3 for better retrieval.
Proposed design
API and Py-Marqo changes
A new optional parameter is added to the search method:
response = mq.index("my-test-index").search(
    "What plants have great heat resilience?", searchable_attributes=["Description", "Title"],
    reranker="openai/GPT3/rerank",
    reranker_api_key="<...api key...>"
)

Marqo changes
Feature implementation

A reranker_api_key parameter is added as an optional paramater to:

As a field in the body of the search endpoint
in tensor_search.search()
in reranking.rerank_search_results()

We create an elif checking for a GPT reranker in reranking.rerank_search_results()

Create a file src/marqo/s2_inference/reranking/openai/gpt3.py which will interface with the GPT3 API.

This will have an entrypoint function rerank(search_results: dict, query: str) -> dict

The prompt, also defined in this file, will have a structure like this:

f"""
    Background:
    {"\n".join["Source {i+1}) {content}" for i, content in enumerate(results)])}

    Query: {question}

    Instruction: rank the sources with respect to relevance of the query
"""

The results from GPT look like this:
1) Source 4: The 15 Best Heat Tolerant Plants (Because the Dog Days of Summer Are Here!)
2) Source 1: 20 Heat-Tolerant Plants That Will Survive (and Thrive) in the Summer
3) Source 3: Top 10 Heat-Tolerant Plants
4) Source 2: 7 Heat-Tolerant Plants that Love the Sun
5) Source 0: Plants That Like Full Sun and Heat

We parse the results to get the original indexes, which will be used to order the results.
4. If we get an error we raise it as an RerankerError and forward the message from GPT3,
Minor refactor to reduce stateful-ness
Make rerank_search_results()operate on a copy of tensor_search.search()'s results

tensor_search.search()
returns a reranked copy of results that are received from rerank_search_results()
In rerank_search_results()
, a copy of the search results is made at the top of the function. This copy is passed to the rerankers
For OWL and text rerankers, this copy is returned (as this copy is mutated by the rerankers)
For the GPT reranker, the output from GPT's rerank function is returned directly

Caveats

Reranking is still only performed against the first searchable attribute

Alternative API design: reranker properties dict
API and Py-Marqo changes
A new optional parameter is added to the search method:
response = mq.index("my-test-index").search(
    "What plants have great heat resilience?", searchable_attributes=["Description", "Title"],
    reranker="openai/GPT3/rerank",
    reranker_properties={
        "api_key": <... your api key here...>
    }
)

An optional dict called reranker_properties of replaces the api_key parameter in the
search endpoint body,
tensor_search.search(),
reranking.rerank_search_results().
The benefit of this approach is that we don't have to keep adding new parameters to the
search endpoint body,
tensor_search.search(),
and py-marqo.search() signatures to add extra reranking parameters. We would only need to handle the new parameters in reranking.rerank_search_results().
The API, however, becomes more nested.

Can add reranker models to the cache in a different way to embedding models

Rather re-ordering the existing documents, attach a new document (e.g.: reranker_output)

Move towards reranking on multiple fields


Show player in only one cell?

How do we actually pause/ play video on button click on that cell? Any simple method?

@StackHelp did you solve this? Thanks in advance.


azurerm_servicebus_topic_authorization_rule slug is  dnsrec

The slug for azurerm_servicebus_topic_authorization_rule  is currentlu dnsrec.
This doesn't make sense. I would assume it would be sbtar following the convention in azurerm_servicebus_queue_authorization_rule

good catch @mcalster, make sense!


Add more Slugs in the list

You can see other types of slugs in the website link that I have given in the readme section. From there you can choose any one.
Before contributing, i request you to visit the website once to see the Slugs that are already there. I would love to see more new ones. It's okay if your favourite slug is included and you still wish to contribute the same. But if that's not the case then please add new unique ones.
Thank You!

Can I take up this task? I'll add a few more slugs! :)

@ani-coder-hacker ya sure, You can contribute in it

Can I work on this?

I added a new slug to the list https://github.com/vikhyatsingh123/SlugTerra/pull/20 here is my PR. Kindly check.

I have added 6 new slugs in the slugs gallery! Kindly Check! (list #24 )

@vikhyatsingh123
Fixed merge conflict for yesterdays pull request #10
should be good now...added new slug Joules

@vikhyatsingh123 in my profile after submitting the PR it is showing ineligible Repo for hacktoberfest, can you please check on that.

yeah please check, after submitting the PR it is showing ineligible Repo for hacktoberfest.
 Maintainers of the repository can add the "hacktoberfest" topic to their repository if they wish to participate.

Can I fix the broken UI and add more slugs?

I added a new one slug. Please fix the repository topic to "hacktoberfest", you typo "hactoberfest".
Thank you!

OK, I am updating it.

Hey Vikhyat! I want to contribute on this project

Hey Vikhyat!  Can I ??

Hey @vikhyatsingh123 i want to contribute in this project. Can I ??

Assign this task to me!!!

hello @vikhyatsingh123 , can i work on this issue and add my favourite card?

Hey @vikhyatsingh123 this seems very interesting can I work upon this and provide my contribution,please assign me this.

@vikhyatsingh123 please assign this task to me.

@vikhyatsingh123 Hey ! i want to contribute in this issue

Hello. i want to contribute!

Please Give This Task To Me

@VishalAggarwal2 @guilhermeorcezi
read above comments

I want to contribute

You all can contribute. no need to comment here

Hi @vikhyatsingh123 , I would like to work on this. can you please assign this to me?


add Internal annotation to remove build warning

@Internal annotation can remove following warnings.
> Task :sqldelight-gradle-plugin:validateTaskProperties
Task property validation finished with warnings:
  - Warning: Task type 'com.squareup.sqldelight.gradle.GenerateSchemaTask': property 'sourceFolders' is not annotated with an input or output annotation.
  - Warning: Task type 'com.squareup.sqldelight.gradle.SqlDelightTask': property 'sourceFolders' is not annotated with an input or output annotation.
  - Warning: Task type 'com.squareup.sqldelight.gradle.VerifyMigrationTask': property 'sourceFolders' is not annotated with an input or output annotation.

hmm
but Don't these lines exist for that purpose?
https://github.com/square/sqldelight/blob/c7d0408cbff478e379421b13bb9c0858a4284532/sqldelight-gradle-plugin/src/main/kotlin/com/squareup/sqldelight/gradle/SqlDelightPlugin.kt#L201-L203
According to the Gradle code, SourceTask#getSource() has @InputFiles annotation, so it should invalidate the task upon file change.

thanks!


pure-component: support Type Annotations & Class Properties

I was going to split this into a few PRs, but they're kinda related.
Firstly, it now treats any Component with a ClassProperty which isn't props as being impure.
Secondly, it retains any static ClassPropertys.
Finally, it retains props type annotations when transforming to a function.
I haven't used jscodeshift before, so happy to make any changes if there's a cleaner way of accomplishing it :)
// input
class PureWithTypes extends React.Component {
  props: { foo: string };
  render() {
    return
;
  }
}

// output
const PureWithTypes = (props: { foo: string }) => {
  return
;
}

Oh, this completely errors when running on my own project.. I guess the default parser of jscodeshift is Babylon, but not in the tests?

@keyanzhang can you take a look at this one? :)

Thanks @danharper, the code looks solid. I manually restarted the build on travis to double check; all the errors are from #88 but not pure-component, so this is good to merge!

👍  thanks


mlh: update Jenkins jobs following 1.24 support

K8s 1.24 support was added in f321a6a8f08321a4997797f6fe17cbad27ddaccc.
As discussed in community meetings, we can't use net-next for testing K8s 1.24 for now, yet need a kernel recent enough so that we can still test dual-stack IPv6: we have settled on using 4.19 for K8s 1.24.
We have rotated the Jenkins test jobs as follow:

Changed: 5.4 bumped on K8s 1.22 (instead of 1.21, triggered on /test).
Changed: Kernel 4.19 on K8s 1.24 (instead of 1.22, triggered on /test).
Not changed: Kernel net-next on K8s 1.23 (triggered on /test).
Added: Kernel 4.9 on K8s 1.22 (not triggered on /test).

See the Table of Truth™ for up to date status on all trigger phrases: https://docs.google.com/spreadsheets/d/1TThkqvVZxaqLR-Ela4ZrcJ0lrTJByCqrbdCjnI32_X0/edit#gid=0

/test-1.22-5.4


Test foamdev.com on iPhone

ping

There's one small problem on desktop safari, which is usually pretty close to iPhone.  Will test on iPhone later today or tomorrow.


feat: Switch solc compiler for Foundry compiler project-wide

Feature Request
Describe the Feature Request
We need more granular handling of the solidity compiler.
For that, we'll use Foundry as the source of truth for EVM bytecode generation.
Describe Preferred Solution

Replace solc,
Replace solc docker scripts,
Install Foundry,
Link foundry compiler with our testing procedure (compilation of .sol files and generation of ABIs / bytecodes)

I can take this one :)


Task: allow "typeOf" presents to match based on superTypes

it is now possible to match mappings based on superTypes (eg. mixins)

Tested it and it works

I will merge this PR this week. Thanks a lots and sorry for the really long response time

https://packagist.org/packages/ttree/crossreference 1.1.1 just released, sorry for the long silence, back on some Neos project


ARROW-4498: [Plasma] Fix building Plasma with CUDA enabled

This fixes build and tests for me.

rebased


[turborepo] passing arguments to running tasks leads to redundant warnings (yarn)

What version of Turborepo are you using?
1.10.12
What package manager are you using / does the bug impact?
Yarn v1
What operating system are you using?
Mac
Describe the Bug
When using turbo run arguments for tasks are passed with redundant -- which leads to the warning scripts don't require "--" for options to be forwarded -> bloated logs -> increased cache size.
The issue is reproducible only with yarn, npm and pnpm work as expected without this warning.
Expected Behavior
Don't pass redundant -- for running tasks to avoid useless warning.
To Reproduce
To reproduce you can use the official yarn example. Change lint script in package.json to "lint": "turbo lint -- --quiet" to pass an argument and run yarn lint. As a result, you'll see the following warning in logs and cache:
ui:lint: warning From Yarn 1.0 onwards, scripts don't require "--" for options to be forwarded. In a future version, any explicit "--" will be forwarded as-is to the scripts.

Reproduction Repo
No response

I was able to confirm. I'll see if I can get that updated.


fix BOSH DNS does not work for app containter

This fixes the issue #84

@dennisjbell Hi I saw you have commits on BOSH DNS, will you have time to review this PR?

I would like to see this as a feature (perhaps named app-bosh-dns), since some people may not want to extend local *.cf.internal name resolution to their containers, as another layer in the defense-in-depth strategy used to keep application containers from mucking about with Cloud Foundry internals.

That is a very good point, thx! I will work on changing it next week.


[ROADMAP] - Support all AWS SDKs

Support for every distributed AWS SDK.

AWS Windows SysAdmins would like AWS Tools for PowerShell


Missing message data

UptimeRobot triggers a message in Rocket.Chat, but the message is empty. See attached.
I've triple checked all configurations and they seem fine.

Eveything is fine with me :

Check your ocnfiguration again, something seems wrong.

@crazy-max I've triple checked and still no luck.
Please see attached screenshots of my configs, in case you can see anything wrong.
Please note we are using rocket on private server, not their cloud.

@RowanBurgess Sorry for the delay, everything seems good to me.
Can you add in the script the following line :
console.log(request.content);

after this one :
msg = buildMessage(request.content);

And give me the output of your RocketChat log please ?

@crazy-max No trouble, no rush.
Please see recent and relevant snippet of rocket log attached.
rocket.log

@RowanBurgess Can you comment this line and check if it works now ?

@crazy-max No good. Same problem, and see log attached FYI
rocket.log

@crazy-max Not sure if this helps, but it seems to be trying to upload a file, rather than add a comment:

@RowanBurgess Logs seems ok to me, are you using a reverse proxy ?

@crazy-max Ah yes, we are!

@RowanBurgess What kind of reverse proxy? (apache, nginx, caddy, traefik ?)

@crazy-max We're using Apache

Can you post your Apache config ? And can you also test without the reverse proxy ?

Close due to inactivity.


Compile Error: expected wasmtime::linker::Linker<_>, found wasmtime::Linker<_>

Lapce Version
v0.1.2-1602-g1f040084
(current master)
System information
Debian 12 (Testing)
Describe the bug
Fresh clone of the repo fails to compile with:
cargo install --path .
Additional information
error:
error[E0308]: mismatched types
   --> lapce-proxy/src/plugin/wasi.rs:378:37
    |
378 |     HttpState::new()?.add_to_linker(&mut linker, |_| HttpCtx {
    |                       ------------- ^^^^^^^^^^^ expected `wasmtime::linker::Linker<_>`, found `wasmtime::Linker<_>`
    |                       |
    |                       arguments to this method are incorrect
    |
    = note: `wasmtime::Linker<_>` and `wasmtime::linker::Linker<_>` have similar names, but are actually distinct types
note: `wasmtime::Linker<_>` is defined in crate `wasmtime`
   --> /home/hoijui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasmtime-14.0.4/src/linker.rs:84:1
    |
84  | pub struct Linker<T> {
    | ^^^^^^^^^^^^^^^^^^^^
note: `wasmtime::linker::Linker<_>` is defined in crate `wasmtime`
   --> /home/hoijui/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasmtime-16.0.0/src/linker.rs:84:1
    |
84  | pub struct Linker<T> {
    | ^^^^^^^^^^^^^^^^^^^^
    = note: perhaps two different versions of crate `wasmtime` are being used?
note: method defined here
   --> /home/hoijui/.cargo/git/checkouts/wasi-experimental-http-8ff76d547b5e2d76/21419eb/crates/wasi-experimental-http-wasmtime/src/lib.rs:347:12
    |
347 |     pub fn add_to_linker<T>(
    |            ^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0308`.
error: could not compile `lapce-proxy` (lib) due to previous error
error: failed to compile `lapce v0.3.1 (/home/hoijui/src/lapce)`, intermediate artifacts can be found at `/home/hoijui/src/lapce/target`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

I image, the most likely reason for the issue is indicated by this part of the above error:
perhaps two different versions of crate `wasmtime` are being used?

cargo tree | grep wasmtime shows that these two versions are in use:

16.0.0
14.0.4

You should use --locked

Thanks, that was it!


feat: update artifactId for fat jar

This moves with-dependencies before version in jar naming.
We decided to publish only one version for both scala 2.11 and 2.12 since our code is all java, and all the scala related lib are "provided" and compatible with whatever classpath provides.

Thanks MJ for incorporating everyone's input. What is project.name supposed to be?

Thanks MJ for incorporating everyone's input. What is project.name supposed to be?

project.version would what's inside version. like 0.1.0-snapshot right now.

project.version would what's inside version. like 0.1.0-snapshot right now.


Address Card Responsive #5490

Issue Reference
Link: https://github.com/bagisto/bagisto/issues/5490
Description

Large Screen

Medium Screen

Small Screen

@devansh-webkul
this is working fine


Add update table button #13

Add update table button
2.edit  table in hover leaf  with  hover editor plugin

https://user-images.githubusercontent.com/42957010/158850763-875d1ce4-fded-4ca4-a000-848d8c8268f4.mp4

@cumany Thank you so much for this feature. Looks good. I have left a few comments. I shall merge it once you close them.


Update Cluster-Operating-System-Rolling-Upgrade.md

Clearly mentioning that rolling upgrade works for all kinds of cluster workloads in the beginning of the document. It's just for Hyper-V and Scale-out File Server clusters the downtime is minimal.

@robinharwood, @Xelu86
Can you review the proposed changes?
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


appengine/php72/cloudsql added region tags

But since these are in appengine/php72/cloudsql/app.yaml already do they really need to be in app-postgres.yaml as well?

Yes! So that users can use the github widget and find the entire postgres app.yaml file if needed from this code snippet.

That makes sense, but then we should make them distinct. So this one should be gae_cloudsql_posgres_settings and the other should be gae_cloudsql_mysql_settings

@angelafunk please update the one in app.yaml to be gae_cloudsql_mysql_settings


Don't show 'None' if there is no location name, just collapse the line

Locations without a location name––they will usually only have location names to distinguish locations where the Organization has more than one location––should not (and previously never did) have the word 'None' in the location name field.

[x] When there is no location name, don't show the location name line.

e.g.,

has this gone to Test @jbeard4 - None still shows for the location name on test atm

No, let me deploy it

This is fixed


LightCurve.correct() does not work with SciPy 0.17

The exception said scipy.interpolate.BSpline not found.  Upgrading from scipy 0.17 to scipy 0.19 resolved the problem for the user.

That makes sense to me: https://github.com/scipy/scipy/blob/4b6f71ab37bda20687ff493669a53cb15fb0b35f/doc/release/0.19.0-notes.rst#scipy-interpolate-improvements

:+1: Thanks @mirca!  You rule New York!


Expose versioning information using Spring Boot Actuator

Task Description
We need to expose our versioning information using Spring Boot Actuators.
In Maven we have the following properties in place:

${project.version} – a built-in Maven property, that shows what the version of the artifact that is being produced is.
${strongbox.revision} – a property, exposd via the org.codehaus.mojo:buildnumber-maven-plugin that could be used to get the exact git revision.

These values could be replaced using Maven resource filtering of the application.properties.
Tasks

[ ] Do properties replacement using Maven resource filtering against the `application.properties.
[ ] Expose the versioning information via Spring Boot Actuators.

Help

Our chat
Points of contact:

@carlspring
@sbespalov
@fuss86

I can work on this one ;)


[feat] Evaluate and log all performance values before asserting them

This is a useful feature for tests that check multiple performance values.
Replaces #334.

Codecov Report

Merging #359 into master will increase coverage by 0.02%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #359      +/-   ##
==========================================
+ Coverage   91.09%   91.11%   +0.02%
==========================================
  Files          68       68
  Lines        8244     8265      +21
==========================================
+ Hits         7510     7531      +21
  Misses        734      734

Impacted Files
Coverage Δ

unittests/test_pipeline.py
97.35% <100%> (+0.12%)
:arrow_up:

reframe/core/pipeline.py
94.76% <100%> (+0.05%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3e2753b...c084e22. Read the comment docs.

@jenkins-cscs retry daint dom


Document supported Python versions and display prerequisites in the README

This PR:

documents the Python versions we support
adds a Prerequisites section to the README
adds a TOC to the top of the README so you can see its contents at a glance.

Partially fixes https://github.com/replicate/cog/issues/196

The version of Python on the host doesn't matter. The Python versions we support are in the Docker container.
In other words, the thing that needs documenting is the available options for python_version in cog.yaml.

Yeah good point. It's not a prerequisite for using Cog per se, more of a prerequisite for your model to actually work. I moved this around and reworded it in https://github.com/replicate/cog/pull/415#:~:text=clarify supported Python versions -- let me know what you think.


TELFE-221 View user profile

Ticket: https://telicent.atlassian.net/browse/TELFE-221
Goal
Amend the DS to allow the following (Graph PR to follow):
Given a user is viewing the Graph app
and /whoami is configured in the deployment
When a user looks at the top right of the screen
Then the user will see their user details in their user profile component as shown in the design.
and then app switcher will now be on the top left of the screen
and still work
if /whoami is not configured
Then the user will not see their user profile component on the top right of the screen.
Work Completed

User profile amended.
App switcher is now in the top left when there is a user profile (previous location retained otherwise, in order not to potentially break functionality in other apps).
Theme handling fixed.

Testing Method

Existing tests
Testing added for new component.

Engineering Notes
This needs to be merged before the related Graph PR will pass pipeline tests (passing locally).

🕵 Review Guidance

General guidance

Generally, approve a PR if it makes the system better, even if it's not perfect. — Google: The Standard of Code Review
The aim of both PR AUTHOR and PR REVIEWER is to get the code merged
Aim for consensus, defined as everyone can live with the outcome

For PR REVIEWER:

Read the ticket & description
Review the code
Request any changes that are essential.
For non-essential comments:

Use prefixes, e.g. "nit: change to Pascal case"

nit: small, non-essential change
obs: just an observation, doesn't affect the PR
idea: a suggestion to think about
q: questions

Use modifiers, e.g. "obs[pr-owner-resolve]: Jim is also editing this file"

pr-author-resolve PR author can resolve after reading
pr-author-delete (rare) delete after reading to avoid confusion

try to add at least a helpful comment per ~500 lines; less if the PR is already busy

For PR AUTHOR:

Aim for enough detail in PR description for things to go smoothly
After requested changes, re-request a review (so the PR shows up in reviews-requested:@me)

@dptelicent Could you do a screen recording showing the Ui changes? taa

I'm quite certain @AlecsMissangu would be cool with the changes. Hit me up if you have lingering concerns.